Re: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7
Indeed I have tried several ways to create and build projects without using CMake at all, and so far no luck--I still get requires elevation errors. I don't have a solution for my problem yet but it appears that whatever it is that is stopping me from building projects, CMake does not cause the problem. Thanks to everyone for the helpful advice, which significantly narrowed down the possible sources of error. Although this is not really a CMake problem, this thread now comes up in the Google search results for symptoms similar to mine, so it seems useful to post a resolution in case someone else comes upon this thread for that reason. Running the IDE as administrator (not as simple as just opening an .sln file, unfortunately), I found another underlying error for which an answer is given at http://stackoverflow.com/a/10890428 . In summary, after I did a web-based installation of Visual Studio 2010 Service Pack 1, I was able to build a project created in the IDE, I was able use CMake to generate projects, and I was able to build the projects generated by CMake. Incidentally, when I first got CMake and the compilers to run correctly, I was only able to do it by running CMake or DEVENV as administrator. Not so coincidentally, somehow during all the installing/uninstalling/attempted fixes I had applied, CL.EXE had been set to run as Administrator for all users. It turns out that when I UNDID this setting (so CL.EXE does not always run as Administrator), CMake and the compilers succeeded without my having to take any special steps to run anything as administrator. Go figure. David -- 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
Re: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7
On 1/6/2015 7:10 PM, david.k...@engilitycorp.com wrote: I have just started using a new Windows 7 host with Visual Studio 2010 Professional. When I call CMake to generate my project files, I get the following output in CMakeError.log: Does your visual studio work without CMake? Can you create a simple project with the IDE and build it? Can you then build that project from the command line like CMake does: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe yourproject.vcxproj /p:Configuration=Debug Indeed I have tried several ways to create and build projects without using CMake at all, and so far no luck--I still get requires elevation errors. I don't have a solution for my problem yet but it appears that whatever it is that is stopping me from building projects, CMake does not cause the problem. Thanks to everyone for the helpful advice, which significantly narrowed down the possible sources of error. David -- 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
Re: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7
What do you mean when you say I set CMAKE_ROOT to a directory ?? That should not be necessary, no matter how you're running cmake... Is that an ENV var or a CMake variable you're setting somewhere? CMAKE_ROOT was an ENV variable used by a script outside of CMake that (in the more complicated build that I was originally describing) would invoke the actual CMake executable. I've been using that script for so long I had forgotten where the requirement for CMAKE_ROOT came from. As it turns out, in at least one of the command windows where I tried the hello world test case, I did not actually set CMAKE_ROOT after all. That symbol (or lack of it) does not seem to have any bearing on the problem I'm experiencing. David -- 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
Re: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7
A small correction: the problem with The C compiler identification is unknown seems to have been due to the fact that I forgot to open that particular command window as administrator. In a new command window, run as administrator, both -G Visual Studio 10 and -G Visual Studio 10 Win64 produce the required elevation error, same as before. Go figure. David -Original Message- From: Karr, David A. @ EngilityCorp Sent: Wednesday, January 07, 2015 12:47 PM To: 'David Cole' Cc: cmake@cmake.org Subject: RE: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7 I tried this with a CMakeLists file that contains only a PROJECT and ADD_EXECUTABLE (with a single C++ source file). The only things present in the directory before running CMake were the C++ file, CMakeLists.txt, and a batch file that I used to run CMake. I still get the requires elevation error even when I run cmake.exe from a command line as administrator. It also doesn't seem to matter whether I select Visual Studio 10 or Visual Studio 10 Win64 as my generator. I thought maybe the problem was that I didn't install CMake, rather (as I've been doing for years, due to the way this project is version- controlled) I set CMAKE_ROOT to a directory that happens to contain the CMake files and then ran a copy of cmake.exe. I just tried the exercise again after doing a regular installation of CMake 3.1.0 (using default choices only) and came up with the same result. (Actually not quite: now -G Visual Studio 10 says The C compiler identification is unknown, and only -G Visual Studio 10 Win64 produces the elevation error, whereas with my previous uninstalled version both generators resulted in elevation.) David -- 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
Re: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7
I tried this with a CMakeLists file that contains only a PROJECT and ADD_EXECUTABLE (with a single C++ source file). The only things present in the directory before running CMake were the C++ file, CMakeLists.txt, and a batch file that I used to run CMake. I still get the requires elevation error even when I run cmake.exe from a command line as administrator. It also doesn't seem to matter whether I select Visual Studio 10 or Visual Studio 10 Win64 as my generator. I thought maybe the problem was that I didn't install CMake, rather (as I've been doing for years, due to the way this project is version-controlled) I set CMAKE_ROOT to a directory that happens to contain the CMake files and then ran a copy of cmake.exe. I just tried the exercise again after doing a regular installation of CMake 3.1.0 (using default choices only) and came up with the same result. (Actually not quite: now -G Visual Studio 10 says The C compiler identification is unknown, and only -G Visual Studio 10 Win64 produces the elevation error, whereas with my previous uninstalled version both generators resulted in elevation.) David -Original Message- From: David Cole [mailto:dlrd...@aol.com] Sent: Wednesday, January 07, 2015 10:58 AM To: Karr, David A. @ EngilityCorp Cc: cmake@cmake.org Subject: Re: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7 The The requested operation requires elevation. message indicates some sort of permissions problem (admin privileges...) Did you run VS and/or CMake as an admin one time, and then not as an admin a second time...? It should work with either all-non-admin runs or all-admin runs, but you probably can't mix-n-match from run to run. Can you start with a very simple hello world app, in a brand new empty to start with directory, and run CMake and VS without admin privileges? Or do you get exactly the same thing if you do that? D On Tue, Jan 6, 2015 at 7:10 PM, david.k...@engilitycorp.com wrote: I have just started using a new Windows 7 host with Visual Studio 2010 Professional. When I call CMake to generate my project files, I get the following output in CMakeError.log: == Determining if the C compiler works failed with the following output: Change Dir: C://__/CMakeFiles/CMakeTmp Run Build Command:C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe cmTryCompileExec.vcxproj /p:Configuration=Debug Microsoft (R) Build Engine version 4.0.30319.17929 [Microsoft .NET Framework, version 4.0.30319.18034] Copyright (C) Microsoft Corporation. All rights reserved. Build started 1/6/2015 6:15:19 PM. Project C:\\__\CMakeFiles\CMakeTmp\cmTryCompil eExec.vcxproj on node 1 (default targets). InitializeBuildStatus: Creating cmTryCompileExec.dir\Debug\cmTryCompileExec.unsuccessfulbuild because AlwaysCreate was specified. ClCompile: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c /Zi /nologo /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D CMAKE_INTDIR=\Debug\ /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /FocmTryCompileExec.dir\Debug\\ /FdC://__/CMakeFiles/CMakeTmp/Debug/cm TryCompileExec.pdb /Gd /TC /analyze- /errorReport:queue testCCompiler.c /Zm1000 TRACKER : error TRK0002: Failed to execute command: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe @C:\Users\\AppData\Local\Temp\tmp9db9bf329c554cb8be447cdb72 535c4e.rsp. The requested operation requires elevation. [C:\\__\CMakeFiles\CMakeTmp\cmTryCompi leExec.vcxproj] Done Building Project C:\\__\CMakeFiles\CMakeTmp\cmTryCompil eExec.vcxproj (default targets) -- FAILED. Build FAILED. C:\\__\CMakeFiles\CMakeTmp\cmTryCompil eExec.vcxproj (default target) (1) - (ClCompile target) - TRACKER : error TRK0002: Failed to execute command: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe @C:\Users\\AppData\Local\Temp\tmp9db9bf329c554cb8be447cdb72 535c4e.rsp. The requested operation requires elevation. [C:\\__\CMakeFiles\CMakeTmp\cmTryCompi leExec.vcxproj] 0 Warning(s) 1 Error(s) Time Elapsed 00:00:00.10 == The only thing I've changed in the output text is I replaced some user-specific directory names with underscores or . This project previously built just fine on Windows XP. Moreover, my coworker, who as far as we can tell set up his Windows 7 host the same way I did (modulo some things that shouldn't matter, such as I have a copy of Emacs and he doesn't), is able to build the same project files without error. It may be
[CMake] Unable to create project files with Visual Studio 2010 on Windows 7
I have just started using a new Windows 7 host with Visual Studio 2010 Professional. When I call CMake to generate my project files, I get the following output in CMakeError.log: == Determining if the C compiler works failed with the following output: Change Dir: C://__/CMakeFiles/CMakeTmp Run Build Command:C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe cmTryCompileExec.vcxproj /p:Configuration=Debug Microsoft (R) Build Engine version 4.0.30319.17929 [Microsoft .NET Framework, version 4.0.30319.18034] Copyright (C) Microsoft Corporation. All rights reserved. Build started 1/6/2015 6:15:19 PM. Project C:\\__\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj on node 1 (default targets). InitializeBuildStatus: Creating cmTryCompileExec.dir\Debug\cmTryCompileExec.unsuccessfulbuild because AlwaysCreate was specified. ClCompile: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c /Zi /nologo /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D CMAKE_INTDIR=\Debug\ /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /FocmTryCompileExec.dir\Debug\\ /FdC://__/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.pdb /Gd /TC /analyze- /errorReport:queue testCCompiler.c /Zm1000 TRACKER : error TRK0002: Failed to execute command: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe @C:\Users\\AppData\Local\Temp\tmp9db9bf329c554cb8be447cdb72535c4e.rsp. The requested operation requires elevation. [C:\\__\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj] Done Building Project C:\\__\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj (default targets) -- FAILED. Build FAILED. C:\\__\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj (default target) (1) - (ClCompile target) - TRACKER : error TRK0002: Failed to execute command: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe @C:\Users\\AppData\Local\Temp\tmp9db9bf329c554cb8be447cdb72535c4e.rsp. The requested operation requires elevation. [C:\\__\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj] 0 Warning(s) 1 Error(s) Time Elapsed 00:00:00.10 == The only thing I've changed in the output text is I replaced some user-specific directory names with underscores or . This project previously built just fine on Windows XP. Moreover, my coworker, who as far as we can tell set up his Windows 7 host the same way I did (modulo some things that shouldn't matter, such as I have a copy of Emacs and he doesn't), is able to build the same project files without error. It may be noteworthy that after this failure, the file CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj does not exist, and there are no files whatsoever in CMakeFiles\CMakeTmp\cmTryCompileExec.dir\Debug. I have been trying all kinds of suggestions I have found by looking up the message The requested operation requires elevation. I have tried setting ownership of the directories (it turns out I owned them all along), I have tried setting access rights (already set to full access), I tried turning off UAC, and I even tried repairing the installation of Visual Studio 2010. None of it made any difference. I've found some Web sites where some people have complained of problems when they had installed Visual Studio 2012 and tried to use Visual Studio 2010. But Visual Studio 2010 is the only version that has been installed on this host. This has had me dead in the water for at least a day, unable to make any progress on my actual project. Does anyone have any ideas about where to even begin to look for solutions I haven't already tried? David -- 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
[CMake] Why do people need so much control over details of their build? (was RE: exe and dll vs. pdb and idb files (was RE: CMAKE_RUNTIME_OUTPUT_DIRECTORY without the extra'Debug' or 'Release' ?))
david.k...@l-3com.com wrote: Brad King wrote: Perhaps the install() command is better for that. it adds an extra step into the procedure Just run make install instead of make. If they used make. But yes, I suppose we could have an Install project in Visual Studio. That would still force a difficult negotiation with my customer, who still has an unresolved software defect report on file asking why my group of developers is using CMake instead of just checking sln and vcproj files into ClearCase like all their other developer groups are. The resolution I'd like to reach for that software defect report is to have all the other developer groups also use CMake so that my group will no longer be the odd one out. But to reach that resolution, I have to sell the idea of CMake to a lot of people. Even to reach the second best outcome--where the other groups don't use CMake, but they stop complaining about the fact that my group does--looks like it will require a major sales pitch at some point. This whole project (my group's part and all the others) has run for a long time already, and it has been using Visual Studio files that have done basically the same thing in the same way, putting the same kinds of files in the same places, for quite a number of years (I'd guess more than 8 years, though I'd have to look back carefully to be sure), with a new distribution prepared every night and frequent installations in various locations. As far as most of the people involved are concerned, the build process for all the parts of the software that don't use CMake are fine the way they are. Every time someone notices that CMake insists on doing something a different way, even if the new way is perfectly logical and reasonable, it's one more reason to complain to me. I think CMake would solve a lot of headaches that the rest of the group has suffered due to their reliance on moldy old Visual Studio project files (for example, immense hacking of their vcproj files so they cou ld do concurrent development in two versions of the compiler, which they could much more easily have solved by using out-of-source builds). But to put this across, I first need people to listen to what CMake can do for them that their current system can't, and it's hard to get them to listen to that when they're focusing on all the things their current build does easily that we can't get CMake to do in exactly the same way. If it were just me messing around with some solo software development, or even just me telling all the developers in my own group that this is the way we're going to manage our builds, I'd be a lot more eager to see if I can use install() to do just what I really need to do (not necessarily exactly what the people around me and I have been doing all along). Even within the larger group of developers, I don't suppose the install() issue by itself would be a deal-breaker. But it's that and all the other similar constraints of CMake that make me concerned I won't be able to sell it--and if I don't make the sale I may lose the choice to use it at all. The install() command was designed to give precise control over the construction of install trees (AKA stages before tarballing). I see no strong need to duplicate this functionality to the same level of precision for the build outputs. There's no need from the perspective of someone who just wants a clear, logical build system. CMake provides one. The problem comes when you want CMake to replace an existing build system around which a large group of developers have already built up resistance to change. I suspect that a lot of the inquiries on the CMake mailing list, and even a lot of the features already in CMake (perhaps even the CMAKE_RUNTIME_OUTPUT_DIRECTORY_* variables, where we started this discussion) are due to the preconceived notions that certain groups of developers already corporately assume about their build procedures, and the need to overcome the inertia of those preconceived notions. By the way, this level of control long ago existed and (AFAIK) still exists for anyone building a Visual Studio 6.0 project in CMake. You can do most of what you need by adding command-line options to variables such as CMAKE_CXX_FLAGS and CMAKE_EXE_LINKER_FLAGS (with SET commands guarded by IF commands so you don't pass these options to other compilers!), and you could do the rest of it by directing the VS 6.0 generator to get its templates from a directory specific to your particular project. I very much sympathize with your aversion to re-introducing all this fine-grained control, if we assume that the only way to do it is to continue down the current path of adding all these little onesie-twosie variables properties literally programmed ad-hoc into the CMake C++ source code in order to tweak this detail and that detail of the build. Just trying to learn to use all these independent features is hard
Re: [CMake] exe and dll vs. pdb and idb files (was RE: CMAKE_RUNTIME_OUTPUT_DIRECTORY without the extra'Debug' or 'Release' ?)
From: Brad King [mailto:brad.k...@kitware.com]
david.k...@l-3com.com wrote:
One thing you can do with one directory full of .exe and .dll files is
to copy it somewhere else—to an arbitrary directory on another computer,
Perhaps the install() command is better for that.
Not if you mean what I think you mean.
Someone will be sitting at host X and will want to copy some code from host Y.
That is, they want to pull code from the machine where the build occurred,
while logged onto a machine that basically doesn't have access to the build
procedure, just to its output. If they have to run a procedure on host Y to
push code from host Y to host X, it introduces extra complexity in their work
day.
It occurred to me that the install() command might be an alternative to the use
of the CMAKE_RUNTIME_OUTPUT_DIRECTORY_* variables. I see two main objections
to this: first, it adds an extra step into the procedure (which would annoy all
my coworkers and break my customer's build procedure, when they're already
giving me pushback about other things that they say CMake can't do); second,
just collecting .exes and .dlls in a directory within ${my_project_BINARY_DIR}
is hardly a bona fide installation procedure, so it seems I'd be badly abusing
the install() command.
___
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] exe and dll vs. pdb and idb files (was RE: CMAKE_RUNTIME_OUTPUT_DIRECTORY without the extra'Debug' or 'Release' ?)
This seems to work for me, too: with a few SET commands, I persuaded
CMake 2.8.1 to put all my .exe and .dll files (from one Visual Studio
2008 solution) in one directory, and all my .lib files in another
directory, without any Debug or Release directory name in either
path.
BUT ...
... and let me emphasize, BUT ...
It also put all the .pdb and .idb files in the same directory as the
.exes and .dlls. So I now have about three times as many files in that
directory as before, making it a little harder to assess what's there.
Moreover, for a typical library, call it xyzzy, the combined sizes of
xyzzy.pdb plus xyzzy.idb add up to about 20 times the size of xyzzy.dll
in the Release configuration-and all of that is now being dumped into
that one directory. This is really obnoxious.
One thing you can do with one directory full of .exe and .dll files is
to copy it somewhere else-to an arbitrary directory on another computer,
for example-and run the software there. Now the transfer time and disk
storage required for this have just increased about 2000%.
This is the main reason why I asked last year for independent control
over where the .pdb files are written (and I should have included .idb
files in that request). Actually I don't really need to redirect the
.pdb outputs separately from all other output; I'd be happy enough (in
this case at least) if they just went to the same place as the .obj
files. What I really want is to control where the executable
files-emphasis on executable-are built, separately from all the other
files that I don't really need at run time.
David Karr
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Erwin Coumans
Sent: Monday, February 08, 2010 1:46 PM
To: David Cole
Cc: Brad King; cmake@cmake.org
Subject: Re: [CMake] CMAKE_RUNTIME_OUTPUT_DIRECTORY without the
extra'Debug' or 'Release' ?
I'm not using SET_TARGET_PROPERTIES,
SET( CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${BULLET_PHYSICS_SOURCE_DIR})
SET( CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE
${BULLET_PHYSICS_SOURCE_DIR})
seems to work just fine for all targets with CMake 2.8.1.
Thanks,
Erwin
On 8 February 2010 10:44, David Cole david.c...@kitware.com wrote:
You have to set the target property to set the directories to something
of your own choosing.
CMake will always use Debug and Release by default for Visual Studio and
Xcode, since they are multi-configuration development environments...
On Mon, Feb 8, 2010 at 1:40 PM, Erwin Coumans erwin.coum...@gmail.com
wrote:
No, I just tried CMake 2.8.1 and it still adds 'Debug' and
'Release' directories to the name.
Are you sure it has been fixed?
Thanks a lot,
Erwin
On 8 February 2010 05:43, Brad King brad.k...@kitware.com
wrote:
Erwin Coumans wrote:
Hi,
How can we specify the actual directory where the executable
ends up in
MSVC, without any messing around by adding 'Debug' or
Release'?
I tried the following lines:
SET( CMAKE_RUNTIME_OUTPUT_DIRECTORY
${BULLET_PHYSICS_SOURCE_DIR})
SET( CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE
${BULLET_PHYSICS_SOURCE_DIR})
SET( CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG
${BULLET_PHYSICS_SOURCE_DIR})
But the generated MSVC projectfiles still add 'Debug',
'Release' to the
directory. How can this additional 'Debug' or 'Release' be
removed?
Coincidentally this is already implemented and is going to be in
2.8.1.
http://www.cmake.org/Bug/view.php?id=9163
-Brad
___
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] include_external_msproject creating duplicate projects in parent solution
Randy Hancock randy.hanc...@gmail.com: I'm getting duplicate projects included in my top-level solution (*.sln file). I have a cmake project() defined at the top level and in the test projects for convenience during development. When I use include_external_msproject in the subprojects it also adds the external msproject to the parent. This is desirable, but lets say both the test/time project and the test/string project include the common lib. This makes common show up *twice* in the parent solution and causes a bunch of unwanted errors in visual studio. I wonder if the concept of a PROJECT command in a subdirectory of your top-level CMake directory is semantically sound. That is, it might work sometimes but cause trouble when you hit one of the not-so-well-thought-out consequences of doing it. I also noticed that CMake really wants to have a PROJECT command in its top-level directory. If you don't put one there, the VC++ 2008 generator will make an SLN file in that directory anyway, using a default project name. This doesn't happen in subdirectories. Here is a workaround based on a technique that I have actually used. Let's say your directory structure looks (in part) like this: /root CMakeLists.txt /test /string/CMakeLists.txt (omitting other files and subdirectories in the directories shown). Moreover, let's say /root/CMakeLists.txt contains the command PROJECT(everything), and /root/test/string/CMakeLists.txt contains the command PROJECT(string_test). Then I would enclose PROJECT(string_test) within some conditional statement that guarantees that the PROJECT(string_test) command will be ignored when CMake is launched on /root/CMakeLists.txt. When that happens, CMake generates everything.sln but not string_test.sln. On the other hand, if you launch CMake on root/test/string/CMakeLists.txt, it will duly generate string_test.sln. One reason I actually did this was that I figured I would not necessarily want string_test.sln every time I generated everything.sln. (Another reason was that I never had confidence that anyone knew what it really meant for CMake to process a PROJECT command in a subdirectory.) This doesn't solve your problem yet, but if you put your INCLUDE_EXTERNAL_MSPROJECT commands inside the same conditional as the PROJECT commands (or in an equivalent conditional), you won't get duplicates of the project in everything.sln. Of course now you have NO copies of this project in everything.sln, and you actually wanted one, so put an INCLUDE_EXTERNAL_MSPROJECT command in /root/CMakeLists.txt (or leave ONE of the commands in the subdirectories outside the conditional, but that seems to me an inelegant and fragile design). David ___ 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] Problem with circular dependencies
Dmytro Ovdiienko dmitriy.ovdie...@gmail.com:
Yeah. By David Cole I should merge A and B. But support right ordering
of 30
projects... that may be not trivial.
Here is something that confuses me. At the beginning of this
discussion, you said there was a CMakeLists.txt file in the root
directory: that is, you have root/CMakeLists.txt. Then I infer from
your description that you also have a file root/A/CMakeLists.txt (do I
infer this correctly?) in order to build a static library in root/A,
and in root/A/CMakeLists.txt you have (in effect, after substitution
for variables) the command:
PROJECT(A)
Similarly you have a file root/B/CMakeLists.txt in which you have (in
effect) the command:
PROJECT(B)
Now, as you requested, I am not going to ask why B depends on A while A
depends on B. But I will ask this: why do you need two PROJECT
commands? Why not remove both these commands and instead place this
command in root/CMakeLists.txt:
PROJECT(MyRootProject)
If you had this command in root/CMakeLists.txt, then you could write
this in root/A/CMakeLists.txt:
INCLUDE_DIRECTORIES(
${MyRootProject_SOURCE_DIR}/B
)
and you could write this in root/B/CMakeLists.txt:
INCLUDE_DIRECTORIES(
${MyRootProject_SOURCE_DIR}/A
)
Then ${MyRootProject_SOURCE_DIR}/B will become root/B after
substitution and ${MyRootProject_SOURCE_DIR}/A will become root/A,
which is what you said you wanted. You don't need to refactor the
source code, just let CMake handle these directories the way they are
obviously designed, as one inseparable group of libraries.
David
___
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] unable to include a source file for all sub directories
ankit jain ankitgu...@gmail.com wrote: My source tree structure is: Main_folder .. Ident.c ..folder1 f11.c f12.c [...] Now I am able to get all the source files from all the folders. but the problem is that all folder source files uses one variable v1 of this Ident.c file.. So the error iam getting while building the library is : unresolved external symbol: v1 (iam working on windows VC++) I suggest the following exercise: use VC++ to create a very simple workspace/solution with just one VC++ project in it that builds a library. Add Ident.c and just a few of your other files (maybe just f11.c) to this project. Then try to build this project. Now either one of two things will happen: 1. You will get the same link errors as before. Then you know your problem is that you have incorrect C++ code; CMake did not cause the problem and cannot solve it. You might then try asking a C/C++ forum what is wrong, but before you do that you should delete as much code from Ident.c and f11.c as possible while making sure you still get the same error when you try to build the code. Then you can post the complete contents of these files when asking your question. (You will probably not get an answer if you don't post code, or if you post more than a couple of pages of code. Many people are willing to help, but not if they have to do a lot of work that you could have done yourself.) 2. You will not get the same link errors. Then you may be able to find some difference in the settings of the projects (between the project created by CMake and the one you created directly in VC++) that explains why there is an error only in the CMake project. I have a very strong hunch you will get the first result. David A. Karr ___ 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] Settings different compile options for diff. files in same folder
ankit jain wrote: I have a folder in which there are 5 files folder a1.c a2.c a3.c a4.c a5.c Out of these from 4th and 5th iam making a library if iam working on windows else with the rest three iam building one library for the folder. Even on windows also iam making this library but making one more library for the files 4th and 5th.,. So if I understand correctly, all systems must build a library from a1.c, a2.c, and a3.c. Windows must build an additional library from a4.c and a5.c, but other systems do nothing with those files. Is there any possible way that you can get this project reorganized so that you have no more than one library built from any one folder/directory? That seems to be the standard practice in my experience. Yes, you can put multiple Visual Studio project files in one folder (and get similar effects from makefiles), but why? Suppose you could organize the files like this: folder +-- library1 | +-- a1.c | +-- a2.c | +-- a3.c +-- library2 +-- a4.c +-- a5.c Then in library1 you would have CMakeLists.txt that sets the appropriate options for a1.c, a2.c, and a3.c, and in library2 you have CMakeLists.txt that sets appropriate options for a4.c and a5.c. In the top folder you would have a CMakeLists.txt that adds the subdirectory library1; this CMakeLists.txt would also add the subdirectory library2 if it built on Windows, otherwise it would not add library2. I have had very good success telling CMake that I want certain subdirectories built only when a certain condition is true. Also, it is very easy to understand what is actually getting built, since I do out-of-source builds (the compiled files are all under a hierarchy of directories completely separate from the directories that hold the source files); the directories where things actually get built are the ones found in the build tree. In your case, all you have to remember is that library2 is Windows only; you don't have to remember the names of all the individual Windows-only files. David A. Karr ___ 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] include_directories per target
Olivier Delannoy olivier.delan...@gmail.com wrote: I would like to set include_directories on a per target basis. I understand that the INCLUDE_DIRECTORIES property is currently on a per folder basis. It is a bit of a problem as I would like to flatten my build and have all my targets generated in a single destination folder. Is there any way to achieve this currently? The per folder basis refers to the source directories or folders. You don't need to flatten the entire source of your project in order to put the built libraries and executables in one directory. Instead, direct the output of each target to the common directory. For example, I have a project under CMake that puts all the executable code in files in one directory, but the source for each target is in a directory completely separate from any other target's source directory. (We don't even allow one target's source to be in a subdirectory of another target.) This seems to me to be a sensible way to organize such a project even if you were not using CMake. David A. Karr ___ 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] Technique for generating projects that depend on generated sources
From: Eric Noulard eric.noul...@gmail.com Can you run the source generator at cmake time ? Yes you are right and I miss that, if the generator is launched at CMake time it may help a lot. Moreover I would say that the source file list generated by the generator may be some kind of CMake file, let's say generated_source.cmake then one may INCLUDE(generated_source.cmake OPTIONAL) in the CMakeLists.txt [...] Thus you would have the usual CMake + build step with an extra CMake run triggered by the build step itself. I have a similar INCLUDE (but not OPTIONAL) in my largest CMake project due to the requests of other developers. They were accustomed to adding new files directly in the Visual Studio IDE and some of them resisted the idea that they would even have to look at a CMakeLists.txt file let alone add the names of their new files there, simple though it might be. The compromise we finally reached was that in each directory where there's an executable or library to be built, CMakeLists.txt uses EXEC_PROGRAM to run a program that searches the directory for all source files and writes a temporary file containing a CMake command that defines the variable LOCAL_SOURCE_FILES to be that list of files. Then CMakeLists.txt does a similar thing to define LOCAL_HEADER_FILES to be the list of all header files in that directory. There are similar tricks for files in subdirectories, though each subdirectory ends up in its own pair of source groups. Then CMakeLists.txt does an INCLUDE on each temporary file, hence defining the lists of files so that they can be made into source groups. The drawbacks to this approach have already been discussed, but two obvious problems are: (1) CMake has no way to know when it needs to regenerate the project files, so you have to remember to run it whenever you add, remove, or move source files, and (2) this technique forces a rigid structure onto your source code tree that not everyone would like. But in this case it has kept the programmers happy for several years, so we've continued to use it. Your situation is different. But the part that is similar is that I think you may be able to find a way to run your generator AND use its output (via INCLUDE) in the same run of CMake, so that you only have to run CMake once to generate everything. (You may also suffer some of the same drawbacks, but I suspect that some ugliness of that sort is inevitable when you have a generator such as yours.) David Karr ___ 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] equivalent cmakelist for this file
that it identifies because . 7. 'make' links the compiled objects to create the executable file abc because ___. 8. 'make' performs the command _ in this same subdirectory. 9. 'make' goes on to do other things not relevant to this discussion, and then it is done. I think you have told us that step 6 must occur somehow, but you haven't really told us anything about how the makefile decides to do this or what else it does. David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How To change VS2005 Output directory
From: LaViolette, Alan alaviole...@overwatch.textron.com thanks that works. It is kind of a hack would be nice if the generator had an option to not append the configuration. It sounds like you need the PREFIX hack. Not sure if it will make the Win32_Debug folder for you though, you'll have to try it and see. http://www.mail-archive.com/cmake@cmake.org/msg14083.html This also appears to be related to issue number 8243 in the CMake bugtracking database: Users cannot adequately control where Visual Studio writes its output files. http://public.kitware.com/Bug/view.php?id=8243 This applies to every version of Visual Studio later than VS6.0, including VS2005. It's nice to know that there is at least some kind of workaround for this particular aspect of the problem. David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Digest, Vol 58, Issue 3
From: ankit jain ankitgu...@gmail.com Subject: Re: [CMake] equivalent cmakelist for this file The objective here to include all the .desc files in the cmakelist and when we make it it should generate the executable for it like if we include abc.desc then after make it should generate a file abc which is executable and a script which has test cases but generated by .desc file only. In order to achieve that guide me how to write cmake list file for it so that it wiil produce equivalent behaviour as normal make does using unix makefiles. When we make to the unix makefiles it is generating the equivalent executable mentioned inthat .desc file. I want to achieve that through Cmakelist files. First of all remember this: Your CmakeList files do not execute any of these things: what they do is to write _new_ makefiles for you. In order to succeed with CMake, what you need to do is figure out how to tell CMake the things that need to be in your new makefiles so that those makefiles will do the _necessary_ things that the old makefiles do. (I stress the word necessary because sometimes makefiles do things that are not really necessary and you can succeed without those things. It sounds like something about these .desc files is necessary to your process, so you have to figure out exactly what that is so you can tell CMake that your new makefiles must do it. But for example it may not really matter what the name of a script is as long as someone executes the script by using whatever name it has; in that case the particular name you have previously seen is _not_ one of the necessary things in your process.) Where CMake can be very helpful is it knows a lot about the things that almost all C/C++ projects require to be done when someone builds them. For example, it is generally the case that there will be directories with C or C++ files in them, and one of the things your makefile must do is to collect a set of C and C++ files from one or more of these directories and build some library or executable from them. All of us here have projects that need this, usually many different libraries and/or executables from various sets of C and C++ files in our source directories, so CMake provides commands such as ADD_LIBRARY and ADD_EXECUTABLE. But it appears that nobody here except you has ever seen a makefile that needs to do something with a .desc file. I suspect that the practice of naming a file something.desc for this purpose is something that is done in perhaps only one organization, or at most in a few geographic regions in the entire world, and that is why nobody here seems to recognize what it is. But you have told us that after your makefile generates some executable from the C/C++ source, it must executed some kind of script that has something to do with your .desc file. On the other hand, many of us have projects where the makefiles have to do some unique things that nobody (or almost nobody) else in the world does, and yet we succeed in using CMake to help us build these projects. So it is very likely that you can do what you want in CMake, but you will have to figure out many of the details yourself, as we have had to do for our particular unusual build steps. I still do not understand exactly what you need so I may guess wrong, but I guess that you might be able to use the ADD_CUSTOM_COMMAND command to tell CMake that the new makefile needs to run your script, and when it should run. You may have to use other CMake commands such as SET to create new CMake variables (which you will have to name) containing filenames and/or command-line parameters for your script, and to manipulate those strings until they are exactly what you need to give as parameters to ADD_CUSTOM_COMMAND so that the resulting makefile will do what you need. I have used ADD_CUSTOM_COMMAND only with Visual Studio projects, not with Unix makefile projects, so I don't know if it would work exactly the same for you as it does for me, but I have found it works pretty well for me once I have taken the trouble to figure out _exactly_ what named script or executable needs to be called with _exactly_ what command-line parameters from _exactly_ what current working directory. I wish you success. David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_library and target_link_libraries in different directories?
My goal would be to have
- each library in it's own directory (and a CMakeLists.txt
file
with a add_library command)
- all dependencies stored in a single file at the root level
root dependency file example:
target_link_libraries(mylib1 mylib2 mylib4)
target_link_libraries(mylib2 mylib2 mylib5)
target_link_libraries(mylib3 mylib4 mylib5)
. . .
As has already been noted, the specification of target_link_libraries is
such that it can occur ONLY in the directory with the corresponding
add_library command.
What you could do is something like this:
In your root dependency file:
set(LINK_TO_mylib1 mylib2 mylib4)
set(LINK_TO_mylib2 mylib2 mylib5)
set(LINK_TO_mylib3 mylib4 mylib5)
In the CMakeLists.txt file in the directory of mylib1:
add_library(mylib1 ...)
target_link_libraries(mylib1 LINK_TO_MYLIB1)
So the target_link_libraries command is where it needs to be, but the
actual list of libraries to link is where you want it to be.
If you really want, I'm sure it's possible to define a macro or function
in your root configuration file, for example MyAddLibrary(lib_name
source_files), that would execute the add_library(mylib1 ...) command
and then execute the target_link_libraries(mylib1 ...) command with a
list of libraries that your root dependency file associated with mylib1.
(In fact the reason my example used variable names like LINK_TO_mylib1
was to try to make such a thing easier.)
By the way, I have a project in which I had a list of several libraries
that I wanted most of the other libraries in the project to link to. So
I have something like this:
In the root configuration file:
Set(MY_COMMON_LIBRARIES mylib6 mylib7 mylib8)
In the directory of some other library such as mylib1:
add_library(mylib1 ...)
target_link_libraries(mylib1 ${MY_COMMON_LIBRARIES} mylib2 mylib3)
This lets me add or subtract library dependencies from a lot of targets
all at once by editing just the root configuration file ... not exactly
what you asked for, but somewhat similar.
David
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Visual Studio build question
The issue I'm seeing, is that if libprovides library project fails to build, VS decides to try and build the libuses library anyway, and then complains that libprovides isn't there. Is this the intended behavior of VS, or did I perhaps set something up wrong in my CMakeLists.txt? This feature was added to VS a few years ago. I first noticed it when I started building code in VS .NET 2003 (version 7.1). In VS 6.0, the build stopped after the first failure. This is actually a good feature if you want to go do something else rather than watch your project being compiled. The compiler did useful work on the libuses library, because it build all the OBJ files correctly. It just couldn't link them. When you come back and find the build failed, and you fix the error in libprovides, you can then finish the build relatively quickly, because the compiler and linker have already done almost all the work that they needed to do after building libprovides. All they have to do really is link the libraries or executables that depended on libprovides. Depending on your project, VS may in fact have correctly compiled AND linked a whole bunch of libraries after libprovides. On the other hand, if you want to sit and watch the compiler, you can always stop the build after you see errors start to occur. So I hardly see a downside to this feature. But of course this is really a VS feature, NOT a CMake feature after all. David ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Strip a prefix from a string
I'm afraid this accidentally went through once already while I was in
the midst of editing it; this time it's for real.
Suppose I have a string called foobar. I want to be able to strip a
specific prefix from that string and have the suffix returned to me.
So if I wanted to strip foo, I would get bar back. What's the
easiest way of doing this in CMake?
I would try something like this:
STRING(REGEX REPLACE ^foo VAR_WITHOUT_FOO ${VAR_WITH_FOO})
Then if ${VAR_WITH_FOO} is foobar, this will set
${VAR_WITHOUT_FOO} to bar.
(I've been using a similar device, except that in my case I'm
stripping stuff from the end of the string.)
-- David
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Object files of a target/source file
In case you wonder why I need the object files: I'm working on porting a rather huge code to Windows which _To_ Windows ... sigh. a) consists of about 70 shared libraries b) has cyclic dependencies between the libraries (yes, i agree...). Under Unix-like platforms this is no problem, but under Windows I need to create an import libraries in order to break the cycle. c) is making heavy use of C++-templates (and typedefs thereof), so identifying the places where I would need to insert these ugly and stupid XXX_EXPORTS macros is just pure torture. If I understand correctly, you don't need a permanent process, you need something that will work once for each of 70 libraries--or perhaps fewer, since some of them may not need import libraries. Then your port will be done and you only have the (presumably less painful) maintenance issues. What about starting with a clean binary build tree (no OBJ files, compile exactly one of the libraries (with build only this project so it doesn't cause any other builds to be attempted), and use the Windows Explorer search capability to see where the OBJ files were written? (A find function that worked in a command window would probably work better, of course.) I don't know if this is a good solution but it might at least be better than the alternative mentioned in (c). David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] source_group() and solution directories
By directories I mean Solution Folders, sorry for the confusion. This is a feature that allows you to add Folders to the solution. This has nothing to do with projects. You can add files to these solution folders. Solution folders are at the same level tree-wise as projects are (Directly under the solution). There are a couple of projects that I have that do not have any implementation files (Don't ask why lol). For these, I need solution folders since creating a project for these won't work- A project needs at least 1 CPP file to be usable. So, for example, I open a .SLN file generated by CMake, look in the Solution Explorer pane of Visual Studio 2008, and see the infamous ALL_BUILD in the list between two of my projects. (I haven't opened any of these projects yet, so the entire list is at one level of indentation below the Solution icon.) ALL_BUILD shows up in this list because there's a file ALL_BUILD.vcproj in the same directory as my .SLN file in the filesystem. And there are no .CPP files that are built by ALL_BUILD itself (though of course ALL_BUILD depends on projects that do build .CPP files). I tend to call ALL_BUILD a project because it shows up at the same level of the hierarchy as all the projects in Solution Explorer and because the proj in the filename ALL_BUILD.vcproj suggests the word project to me. But I suppose technically I should call it a target. Anyway, I'm pretty sure now I completely misread the earlier email. Not so sure I read it correctly this time, though. I'm hoping source_group() can be used without any project and simply add solution folders to the solution. Actually this seems counterintuitive to me. There's no other case in which SOURCE_GROUP by itself would cause a .VCPROJ file to be generated. And the icon that shows up in Solution Explorer looks like a little manila file folder (the kind you could buy at a stationery store in 1970, before some genius decided it was a synonym for filesystem directory), whereas the icon for a project in Solution Explorer looks completely different (but is identical to the icon for ALL_BUILD). I guess one could question why one level of the hierarchy is different from all other levels, but it _is_ different (blame the designers of Visual Studio) and I think it would be too confusing to pretend otherwise. Also, you specifically don't want any source files in the thing you're creating, which seems already to say it's not a source group. It seems to me that what you want is a command that you can use instead of ADD_LIBRARY or ADD_EXECUTABLE to create a new target. Actually I think there are some such commands; maybe one of them does what you want (but if so, someone else will have to explain it, because I don't know how to use any of those commands). Otherwise, it seems to me you need a new command. David ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Automatically listing source files with GLOB (Re: How to make FILE() append to the list of files?)
find . -name *.c source_files.txt edit source_files.txt and put that list of files exiplicitly into a CMakeLists.txt file. file(GLOB is a bad way to get source lists for CMake. CMake has no way of knowing when new files have been put in the directory. But unless I am missing a fundamental feature somewhere, GLOB still seems to be the better alternative. While it may not intrinsically know when new files have appeared on the filesystem, the programmer can simply re-run the CMake command to get an updated project with the newly added source files without editing the CMakeLists.txt file directly. Yes but when he add a source file, he won't necessarily remember he MUST rerun CMake manually [...] Whereas with hard-written sources files in CMakeLists.txt, the user will get accustomed to simple CMakeList.txt editing [...] [...] It usually looks like a better alternative (but I may be wrong) when you are in the process of converting several project to CMake and you end-up writing a lot of boring CMakeLists.txt in the startup process :=) Actually, when I was last faced with this task I decided the easier alternative for me was to cut and paste a lot of boring directory listings into my CMakeLists.txt files. (This was in a much earlier version of CMake, and IIRC there was some problem with file globbing back then that was fixed soon afterward.) The reason for my choice at that time was user acceptance. I had a brief window of opportunity to introduce a new build system based on CMake, which did not give me time to train all the developers in CMake before deploying it. One of the first objections I received was that it was much harder to add, remove, or rename source files in CMake than via the Visual Studio interface. So I made it a pushbutton process: the developer just had to run a script named something like MakeWorkspace.bat. Besides the project developers themselves, I also had users who needed to be able just to build the project without doing any development on it. I actually got in trouble with those users on account of the one directory where I had listed the source files individually instead of globbing them. The problem was solved when we globbed that directory too. I've had second thoughts about all this, for example the other day when someone forgot to tell a developer newly introduced to this project that he needed to run the script after adding source files--that is, we forgot until he came to me asking about his link errors. On the other hand, it takes very little time for people to develop new habits that tell them when to re-run the script. I'm probably going to change some things about the build procedure sooner or later, but I don't know if or when this will be one of them. The conclusion for me is that when I write a CMakeLists.txt file for a personal project, I never glob the files; but the build design of a long-running project needs to account for who is working on it and what procedures will work best for them. That may imply listing the files explicitly, but it could conceivably imply globbing them. David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Controlling the locations of files produced by Visual Studio
The context of this question is that I'm porting an existing project from Visual Studio 6.0 to Visual Studio 2008. This project has used CMake for several years, but before that it already had its own file structure into which it put all the files that it built. [...] It would be ever so much easier for me if CMake just provided a couple of extra options to say where certain output files got written. Another alternative might be to have CMake generate Visual Studio 6 project files, using the variable that controls whether or not CMake rules get added to turn off the re-run CMake rules and then use Visual Studio 2008 to convert those project files...? This would be a viable alternative if I wanted to check in the VCPROJ files under source code control and abandon CMake for all future versions of the software under this project. Which I don't. (I actually did this once just to see what I really wanted the VCPROJ files to look like, so I can confirm that it does work, but it would never be accepted as part of the nightly build process of the larger system.) Since there seems to be no other comment on the mailing list, I'll try the issue tracker. David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatically listing source files with GLOB (Re: How to make FILE() append to the list of files?)
When the decision to change the build system for whatever reason, just tell your developers to not complain about it. Tell them to live with it _POINT_. The point is, not everyone who is in a position to introduce a useful tool into a project is in a position to do it in that way. Sometimes it has to be sold to other people rather than dictated. Besides the project developers themselves, I also had users who needed to be able just to build the project without doing any development on it. I actually got in trouble with those users on account of the one directory where I had listed the source files individually instead of globbing them. The problem was solved when we globbed that directory too. They change nothing on the project? Why would the source file listings be a problem for them, then? I forget the exact sequence of events, but as I recall, the inconsistency was introduced somehow during one of the steps between the actual developer's build and when the source code (including CMakeLists.txt) ended up on a certain source code control branch. All these other users did was to check out all source code on that branch and attempt to build it. Presumably a similar outcome could have occurred via a different chain of events with DSP files that were maintained directly through Visual Studio, but that argument didn't impress people who chose to blame the problem on the fact that we used CMake. What I think is really remarkable is that despite all the many implicit requirements of the environment within which this particular build system had to operate--of which I've barely been able to mention a small part--CMake was able to adapt to work within them, even when those requirements didn't match anybody's idea of the best environment within which to use a tool like CMake. This says something about the power of the tool. David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Passing parameters via command prompt
2008/11/26 Eric Noulard [EMAIL PROTECTED] if you want to batch all those builds then may be you should always start from a pristine empty build dir, thus you won't have to bother on pre-existing cache since there won't be any. I have a project where I create a pristine empty build dir every time I want to try a new configuration (e.g. Release vs. Debug). But I have to confess that due to some other impediment I ran into regarding cache variables--so many years ago that I've forgotten what it was--the setup script for that project, before it calls cmake.exe with my chosen options, DELETES the CMakeCache.txt file. So I never have to wonder whether a definition came from the cache or from somewhere else. Every variable or property we have ever set on that project is specified either by a CMakeLists.txt file or on the cmake.exe command line (placed there by the script that calls cmake.exe); nobody configures that project through the GUI. Maybe that's why I've never noticed any trouble caused by deleting the cache. There's probably a more elegant solution, but since one line in a script apparently fixed the problem, I haven't looked for another way. David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Controlling the locations of files produced by Visual Studio
(CMAKE_EXPLICIT_IMPORT_LIBRARY_DIR ${MY_LIB_DIR})
this would be equivalent to setting the command-line options
/out=${MY_DLL_DIR}/project1.dll and
/implib=${MY_LIB_DIR}/project1.lib for the Visual Studio linker. (I
suppose it could also cause the Unix makefile to produce
${MY_DLL_DIR}/project1.so and/or ${MY_LIB_DIR}/project1.a when
appropriate.)
I thought perhaps the property IMPORTED_IMPLIB might do some of what I
want, but I haven't figured out how to use it at all.
What I actually have implemented (to assist my port to VS 2008) is a
modification of CMake 2.6.2 that supports something like this:
SET(EXPLICIT_OUTPUT_FILE_NAME ${MY_SHLIB_DIR}/project1${SHLIB_EXT})
SET(EXPLICIT_IMPORT_LIBRARY_NAME ${MY_LIB_DIR}/project1${LIB_EXT})
In other words, I can hack one or two classes in the CMake source to do
everything I want, and I can probably get away with this, since the
people who run the build script will just use whatever copy of cmake.exe
I hand to them. But I would prefer to use existing CMake functionality
if it exists; and if it doesn't, I wonder if it would be worth adding
this functionality as an option to CMake. (My hacked version actually
acts exactly like CMake 2.6.2 if you don't use any of the three or four
new variables I defined.)
David Karr
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Making ALL_BUILD be Visual Studio's startup project
In a certain project where we started using CMake about five years ago, it used to be that when we opened the Visual Studio 6.0 workspace created by CMake, the ALL_BUILD project was conveniently defined as the startup project already, meaning that all one had to do was to click the Build button (or press F7) to build the entire workspace. (OK, the project probably should have used at least Visual Studio .NET by that time, but that's another story entirely.) I've noticed that in Visual Studio 7.0 (.NET) and later, ALL_BUILD is no longer defined as the default startup project. It is not vital to my project that ALL_BUILD be the startup project by default, but it was convenient (at least saving a few mouse clicks to change that setting). I think I know why this broke and at least one way to fix it. Is this something other people would find useful? If so, keep reading. As it turns out, the behavior that I thought was so convenient in the workspace generated for VS 6.0 appears to be an accident. In cmGlobalVisualStudio6Generator.cxx, ALL_BUILD and the other projects are stored in an std::map (typedef'd cmTargets) whose key is the name of the project. The iterator over this map visits the targets in lexical order, in which it just happened that ALL_BUILD was first among all the target names in my project (not hard to do when the name starts AL). Hence it gets listed first in the workspace. And apparently Visual Studio sets the first project in the workspace as the startup project by default. In cmGlobalVisualStudio7Generator.cxx, on the other hand, the projects are stored in a cmGlobalGenerator::TargetDependSet, which it turns out is really an std::set of pointers to the targets. Again, the first project listed in the workspace (or rather the solution) is the startup project, and again the iterator visits the targets in sequence, only this time I believe the first target visited is whichever one is closest to the start of virtual memory. Generally, this is not ALL_BUILD. It turns out to be fairly simple to force the ALL_BUILD project to be first in the workspace/solution. (Unfortunately there are two independent code changes needed if this is to be done for both the VS6 and VS7 generators, due to the completely different data structures used, and the new code would be more efficient for the VS7 generator if it used an std::map rather than std::set). The fix is to modify the function that actually writes the workspace/solution file so that instead of just iterating over targets, it looks for the ALL_BUILD target first, does what it needs to do for that target, then iterates through all the targets EXCEPT the ALL_BUILD target. I have versions of cmGlobalVisualStudio7Generator.cxx and cmGlobalVisualStudio7Generator.h that do this; the change to each file is highly localized. I suppose with a little more effort (and almost as simple a change in the code) one could make this happen only if requested, for example by SET(CMAKE_DEFAULT_STARTUP_PROJECT ALL_BUILD), which would let you choose a different default startup project if you like. So, the question: Does anyone want this? David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ALL_BUILD and ZERO_CHECK
Robert Dailey wrote: The only trouble these projects are causing me is clutter. There is no functional purpose for them as far as I know, which is another reason why I do not like them. You could try this: set(CMAKE_SUPPRESS_REGENERATION TRUE) I think that will get rid of ZERO_CHECK, but I am not sure. Again, this will potentially break your builds, and make them less reliable. ZERO_CHECK is used to make sure that the project files are up-to-date relative to the CMakeLists.txt files. It is also used to check some depend information that VS does not do. And what this supports is the ability to incrementally build the VS project files themselves, not just the source files in the projects. What I've noticed in Visual Studio 6 builds using CMake--which don't have a ZERO_CHECK project--is that I edit one of my CMakeLists.txt files, then click Build, and sure enough CMake generates a new DSP file for that project; but then it continues building that same project without reloading, which of course doesn't do what I want, and I have to click Build again in order to make my project compile the way it's supposed to. And sometimes it still doesn't quite recover correctly. In my current Visual Studio 2008 builds using CMake, this process appears to work smoother--and I'm guessing it's because these builds have a ZERO_CHECK project. But if you were still thinking of the Visual Studio files as static source files that you edit by hand, then you wouldn't think of the CMakeLists.txt files as source files on which you might want to detect changes and trigger incremental builds, just as you trigger an incremental build when you edit one of your C++ source files. So yes, clearly you can make all your own vcproj and sln files directly in Visual Studio and build software successfully. I just got sick of continually cutting and pasting in and out of awkward windows and clicking on all the numerous things I had to click to get each project's settings correctly, and CMake offered a way to avoid all that nonsense by defining all the repeated stuff once in a kind of macro, and furthermore an easy way to do out-of-source builds, which I could do with make but could never see a practical way to do from within Visual Studio's own project editor. Moreover, I found that CMake really could produce both a Visual Studio workspace and a Linux makefile for a substantial project, giving me both of these for less than it cost me just to port a workspace to a makefile by hand. In that substantial project, the handy thing about ALL_BUILD was that it was in fact the one project you could build if you wanted everything in the workspace to be built; several of the other projects were executables, each of which had nothing except ALL_BUILD depending on it, so without a project like ALL_BUILD we would have had either to build every single one in succession or else to invent some other (much worse) artificial dependency between projects. But even in a simple project where there's already one project that depends on all others, I'd live with the existence of ALL_BUILD in return for all the other stuff. At least it doesn't actively _prevent_ me from doing something I need to do. But if you really love a carefully crafted Visual Studio solution, with every box in every project carefully and individually filled in or checked off or left empty by a human hand with loving personal care, then CMake is not for you. David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ALL_BUILD and ZERO_CHECK
From: Robert Dailey [EMAIL PROTECTED] Ah, okay. If it manages synchronization between the CMakeLists.txt files and the vcproj files I can understand the need for them. I guess I should have first asked what they are for instead of immediately trying to get rid of them :) Oh darn, my long-winded (and now evidently unnecessary) reply to an earlier posting crossed this one in the mail. Sorry about that; I hope it doesn't waste anyone's time but mine. David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Converting a VS Build to CMake/Problems with Post-Build steps, questions
From: Anteru [EMAIL PROTECTED]
I'm currently converting a fairly large project over to CMake.
This is how I got into CMake, albeit without the x86/x64 wrinkle. It
took some effort to switch the project over, but I am very glad we did.
Caveat: The following is based on a much older version of CMake which
I've been using for the same project for about five years.
* I want to name my debug libraries with a trailing 'd'. I use
SET_TARGET_PROPERTIES(MyTarget PROPERTIES DEBUG_POSTFIX d) to do
this.
However, MyTarget is a unit-test runner and I want to execute it using
ADD_COMMAND as described here
http://www.cmake.org/Wiki/CMake_FAQ#How_do_I_generate_an_executable.2C_t
he
n_use_the_executable_to_generate_a_file.3F
albeit without the output:
GET_TARGET_PROPERTY(PRJ_UT_TARGET MyTarget OUTPUT_NAME)
ADD_CUSTOM_COMMAND(
TARGET MyTarget
POST_BUILD
COMMAND ${PRJ_UT_TARGET} VERBATIM
)
This works fine for release, but not for debug, as it always returns
the
name without the prefix. How is this supposed to work?
We've always done it like this on the biggest project I have under
CMake:
ADD_CUSTOM_COMMAND(
TARGET my_target
COMMAND ${my_project_BINARY_DIR}/my_path/my_unit_test
)
In cases where we needed the debug file name to be different from the
release file name, we defined a variable for that file name, with an IF
command to determine whether the variable is defined as the release file
name or the debug file name. Then we would just write ${MY_UNIT_TEST}
instead of my_unit_test. But we also invoke CMake from a script that
sets the variable BUILD_RELEASE when we want to build in release mode,
so we have an obvious IF condition. I suspect there's a way to test for
debug or release if you don't do this, but I've never bothered to find
out.
* Is there a way to force both Debug and Release to end up in the
same folder? The VC++ project builder seems to put Debug into
EXECUTABLE_OUTPUT_PATH/Debug always, and I found no way to force it to
put both into the same. Rationale behind this is that my project needs
some more files in order to run, and I'd like to put the binaries
right
into this data folder (instead of copying the data around during
pre/post-build ...).
We do this:
SET(CMAKE_LINKER_OUTPUT_FILE
${my_project_BINARY_DIR}/my_path/my_executable)
Actually, we use a CMake MACRO definition to invoke this and a bunch of
other commands on each library and executable we build, so we have, for
example, ${exe_file_name}.exe instead of my_executable for an
executable output, where exe_file_name is a parameter of the MACRO.
But that's because we build many libraries and executables, and it would
have been quite tedious to have to maintain all the commands for each
one independently.
There's probably a way to do these things that uses CMake to do more of
the details, but I've taken the approach to rely on CMake to get the
basics right (which it does very well, for things that would be very
hard for me to do without it), and to do the fancy stuff myself on top
of that. That's why I have about four or five different scripts to
invoke CMake with different sets of variables defined depending on what
kind of build I want to make.
David Karr
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
From: Eric Noulard [EMAIL PROTECTED]: I used Java for 4+ years (all thoses years are overlapping :=) it was really pleased using it for cross platform GUI. And I was really disappointed because the java I used was lacking generics such that I need to cast here and there when using container. This may be a little off-topic, but generic types were added to Java at least two years ago. So, for example, you now can declare an object of type VectorString. Generic types are also useful for a lot more than just avoiding casts when getting objects from containers. I hope I've already put you on the road of there is no FAR better language than other. This is an excellent point. Unlike any specific language feature, this statement is not likely to be falsified by the language designers at any time in the near future. Personally, I find the macros of CMAKE a little awkward at times, but when I want to do anything more sophisticated, I am very happy to write a little helper script or program for CMAKE to invoke. I converted the build of one of my group's software projects to CMAKE a few years ago and it's served us very well ever since, though we now have more than 1800 source code files distributed among nearly 50 libraries and executables. David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
