<div class="gmail_quote">On Fri, Jun 5, 2009 at 1:13 PM, David Cole <span dir="ltr"><<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You might want to open an issue that is a feature request that asks for exactly what you think you want....<div><br></div><div>There are several already open that talk about / have patches for adding support for WinCE and Symbian via adding CMake generators.</div>
<div><br></div><div>At least these 3 (and probably more) already touch on the topic:</div><div><a href="http://public.kitware.com/Bug/view.php?id=8486" target="_blank">http://public.kitware.com/Bug/view.php?id=8486</a><br>
</div><div><a href="http://public.kitware.com/Bug/view.php?id=8102" target="_blank">http://public.kitware.com/Bug/view.php?id=8102</a></div>
<div><a href="http://public.kitware.com/Bug/view.php?id=7919" target="_blank">http://public.kitware.com/Bug/view.php?id=7919</a><br><div class="gmail_quote"><br></div><div class="gmail_quote">Unfortunately, some of these take the approach of adding more and more CMake generators rather than simply using the existing generators and adding platforms. Granted, there are several things to consider in a re-design that would allow extending to platform-organized sln/vcproj files... but I think it would be better in the long run than simply adding new CMake generators every time somebody wants a new architecture in a Visual Studio project.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">The main issue is TRY_COMPILE results. They will be different for different architectures. Of course, strictly speaking, you could construct try_compile calls that give you one result in a Debug build and another in a Release build, right now. (Different build time configs may results in different results...) So.... really try_compile needs to be avoided or somehow account for different configs and platforms for a project to work as expected after being configured by CMake. (Iterating over all generated configs/platforms and storing separate results keyed by config and platform would be one approach...)</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Looking forward to more discussion.....</div></div></blockquote><div><br>How would you handle target_link_libraries() and, ultimately, find_library()? Most people using VS that would want this feature added probably already have many of their dependencies setup with find_package() and/or find_library().<br>
<br>I guess I'm not a big fan of this idea, not because I don't think it might be beneficial, but just because it goes against the CMake design which has always been "one compiler at a time" and I think would be hard and/or hacky to implement.<br>
<br>Instead, how about retrofitting CMake gui with tabs each of which is a build configuration/build directory. The user could choose which generators he wants on initial configure via dialog box (similar to how it is now) but click a big "configure all" button which kicks off n threads and runs configure on all of the tabs creating multiple build directories for each configuration. If there are any issues, he could dive into each individual build configuration and modify things. The "generate all" button wouldn't work until all build trees have no more modified variables.<br>
<br>For VS, you would still have to open up your IDE twice (or switch solution files) but at least you could configure both builds simultaneously in the same application. Also some IDEs like Eclipse would allow you to have each solution file open in the same window so you could build them simultaneously.<br>
<br>This feature, if implemented would also be a great help for the Makefile generator.<br></div></div><br>-- <br>Philip Lowman<br>