Re: [CMake] Visual Studio - Ninja Generator
rate a C# project file for each C# project - even when using non-VS generators like Ninja. The Ninja build rule for a C# project would just be to invoke MSBuild.exe and build that one project. (Only generate projects, not solutions.) But this requires the ability for a CMake language to invoke the MSBuild-generating code inside CMake to spit out a Visual Studio project for each C# target. Benefit: now CMake doesn't reimplement undocumented behavior of Microsoft's MSBuild targets; we just use them directly as a black box. Best regards, James Johnston From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Guillaume Dumont Sent: Monday, August 31, 2015 16:49 To: Gonzalo Cc: cmake@cmake.org Subject: Re: [CMake] Visual Studio - Ninja Generator @Hendrik Sattler I have not experimented with the /MP flag that much, but this won't solve my problem when the project contains a lot of CUDA files. The /MP flag as not effect there. Yes I could indeed create a custom build target and create additional build trees to build using ninja in there but this is suboptimal in my opinion. @Gonzalo Yes this is precisely what I do but then you only get the ninja build files. No solution for debugging etc. My question is more about the difficulty of creating a new generator that makes the use of ninja as transparent as possible to the user instead of writing custom CMake code to do this in my own projects. On Mon, Aug 31, 2015 at 12:29 PM, Gonzalo wrote: s it has changed names a couple of times). That shoul -- Guillaume Dumont = dumont.guilla...@gmail.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Visual Studio - Ninja Generator
Hi, The problem with /MP in cl.exe, /CGTHREADS in link.exe, and /MAXCPUCOUNT in msbuild.exe is they don't communicate with each other, potentially leading to massive over/undersubscription of the system. I would love it if Microsoft could get this mishmash cleaned up somehow so they can all communicate and not oversubscribe the system. (Out-of-the-box, Visual C++ ought to have this straightened out). In theory it would be faster than Ninja because the /MP switch reduces forking overhead and fixed overhead initialization cl.exe by batch building. In the meantime, Ninja seems faster in practice, because it can properly avoid oversubscription with building individual C++ files and entire projects in parallel (whereas cl.exe and msbuild.exe cannot). (One problem with link.exe /CGTHREADS though is that Ninja needs to be told how many threads link.exe will actually use, so that Ninja doesn't oversubscribe. I'm not aware of a way to make Ninja do that though. You can use pools to restrict to one link at a time, but moderate oversubscription will still happen with the concurrent cl.exe instances.) Best regards, James Johnston From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Hendrik Sattler Sent: Monday, August 31, 2015 15:49 To: Guillaume Dumont; cmake@cmake.org Subject: Re: [CMake] Visual Studio - Ninja Generator Hi, did you really enable parallel compiling in VS with /MP24 or the like? Note that using devenv to build uses the number from the IDE user settings but using msbuild needs a command line option. Else just create a custom target that calls cmake for ninja and afterwards ninja itself in yet another build tree. you can limit the creation of that target to if(MSVC_IDE). HS Am 31. August 2015 16:35:01 MESZ, schrieb Guillaume Dumont : Hi all, I would like to know what kind of effort would it take to generate a Visual Studio generator that bypasses the normal MSBuild build and uses Ninja instead. I have been working on different projects which build much faster with ninja than MSBuild (several orders of magnitude on a machine with 24 cores). Still I like to use the Visual Studio environment to use the debugger. Using ninja is especially useful for projects with a lot of CUDA files which are built sequentially for every target using MSVS. I would like to contribute but I don't really know where to start and if such an effort already exists. -- 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] How to depend on external cmake projects?
> -Original Message- > From: rcdai...@gmail.com [mailto:rcdai...@gmail.com] On Behalf Of Robert > Dailey > Sent: Sunday, August 23, 2015 02:43 > To: James Johnston > Cc: CMake > Subject: Re: [CMake] How to depend on external cmake projects? > > On Mon, Aug 17, 2015 at 10:17 AM, James Johnston > wrote: > > Well, you'd do this in conjunction with ExternalProject_Add. A > > well-written CMake external project will provide a > > Config.cmake file which you will then find using find_package. > > After toying around with this idea for a bit, I've found out that > ExternalProject_Add() actually builds the project from a custom target within > Visual Studio (I'm using VS as my generator). However, > find_package() works at CMake configure time, so this is a chicken & egg > problem. find_package() won't work because the external project has not > been built yet. > > How do you solve this problem? By following the following suggestion from earlier: > > > A high-level CMake project that does nothing but call > > ExternalProject_Add; this is called a superbuild. Your own CMake > > projects will be ExternalProjects to this high-level project and the > > superbuild would pass the location to your project via > > -D_DIR= so that find_package can locate the Config > file. > > I'm not sure I understand this. This smells related to my question above, > maybe an answer even. Can you clarify/go into more detail? > Thanks a bunch. Here is an example: https://github.com/InsightSoftwareConsortium/ITKWikiExamples/tree/master/Superbuild This CMakeLists.txt is the root CMakeLists.txt for the superbuild. Notice that: 1. It calls ExternalProject_Add to build VTK/ITK, **as well as** its own project. 2. find_package is not called from the superbuild, thus avoiding the chicken and egg problem. Best regards, James Johnston -- 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] How to depend on external cmake projects?
> -Original Message- > From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert > Dailey > Sent: Sunday, August 16, 2015 13:32 > To: CMake > Subject: [CMake] How to depend on external cmake projects? > > There are certain repositories on Github I'd like to pull in as a dependency. > These repositories already use CMake to build their source code. Based on > personal experience and reading material online, there are a couple of > different options: > > 1. Pull down the repository as a submodule to my own git repository. > Then call add_subdirectory() on it to make it part of the build, allowing me to > refer to those targets as dependencies in my own targets. That's one way to do it. It might be a good way if the dependency is relatively small. Benefits: * Simpler/flattened build process (no hierarchy of makefiles are generated) * No need to delete timestamp files generated by ExternalProject_Add if you need to incrementally build the project. Problems: * Everything must be built with same compiler, generator, build settings, etc. (benefit for some projects, a problem for others). * The dependency must use CMake. * Potential for interference between CMake variables/properties set by your top-level project and your included submodule. ExternalProject_Add is guaranteed to work because this can't happen, but add_subdirectory is not guaranteed to work. * Incrementally building a bunch of these projects, or a big project, could be slow (e.g. your make tool has to check if the files in the submodule changed, in addition to your own. ExternalProject_Add sidesteps this with the timestamps). > > 2. Use ExternalProject_Add(). This seems like legacy, I'm not sure if I should > use this. It also seems very verbose and boilerplate. I don't think it's legacy at all, lots of projects use it. It exists because of the problems of add_subdirectory shown above. The downside is you get these goofy timestamp files you have to manually delete now & again if your submodule changes. You can still include the project as a submodule, just use SOURCE_DIR parameter to pass the submodule path and skip the preliminary steps before CONFIGURE. Even if CMake in the distant future supports different C++ compilers/architectures in the same project, there will still be a need to build non-CMake dependencies and thus a place for ExternalProject. > > 3. Use packages. The [CMake package documentation][1] does not go into > great detail on support for both installed versions and build tree for a single > package. Does this require two scripts? Can it share a single one? Where are > the examples? Well, you'd do this in conjunction with ExternalProject_Add. A well-written CMake external project will provide a Config.cmake file which you will then find using find_package. > > How do I accomplish this? > A high-level CMake project that does nothing but call ExternalProject_Add; this is called a superbuild. Your own CMake projects will be ExternalProjects to this high-level project and the superbuild would pass the location to your project via -D_DIR= so that find_package can locate the Config file. Best regards, James Johnston -- 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] Managed C++ / C# Projects: Location of assembly DLL
> -Original Message- > From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert > Dailey > Sent: Wednesday, August 05, 2015 19:02 > To: CMake > Subject: [CMake] Managed C++ / C# Projects: Location of assembly DLL > > I am including external MS projects via CMake for my C# projects. The > Managed C++ projects I generate via CMake directly. However, sharing > assembly references between the two is difficult. > > Sometimes I need my imported C# projects to know where to find the > managed C++ DLL assembly it built. This is in the CMake binary directory, > which might be different on each machine, so I can't exactly setup a relative > path to this file in the C# project references section. > > Likewise with dependencies on C# output from Managed C++. It's a little > easier to tell CMake where to find the output DLL file for a C# project (since > the output location is relative inside the source dir). > > How do you guys recommend solving these dependency issues? Is there a > way I can add an assembly reference to a Managed C++ project via path > through CMake? I also need to use C#. Until CMake has first-class C# support, I hacked together a primitive "csproj" file generator in about a day and a half (excluding the wrong approach I initially took). I also had problems with "how do you deal with references" and "how do you get the C# project to do an out-of-source build?" (I don't want the C# projects touching my source tree, it's not the CMake way.) So initially I investigated calling csc.exe directly as a custom build step but that approach will have two problems: * No IntelliSense support for C# in the IDE because a C++ project is emitted. * More importantly, system references are difficult to resolve. To see what I mean, built a Hello World C# app in Visual Studio and look at the MSBuild invocation to csc.exe. Note they don't specify "/reference:System.Core.dll" on the command line. Instead we end up with a full path to something like "/reference:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll" - which is a different path from what is used at runtime (GAC path "C:\WINDOWS\assembly\GAC..."). If you Google there are good reasons to link with the reference assembly and not the one installed on your system. Well it turns out that MSBuild has a complicated set of rules for resolving references, they are not well documented, and they are found in your Microsoft.Common.targets file (search for AssemblySearchPaths to see the list of 9 locations it checks). These rules are different and lengthier than the ones used by csc.exe if an absolute path is not provided. So here's my suggestion: 1. Generate a csproj file on-the-fly from a template and put it into your binary dir, given a list of source files, target name, references, etc. That solves the out-of-source build problem. Make a reusable CMake function(s) for adding C# targets which handles the steps here. 2. Use either include_external_msproject if using a VS generator, or create a custom command/target to directly invoke MSBuild if using a non-VS generator. 3. For references, if you will be using include_external_msproject (as opposed to custom target), and the reference is not an imported target, you will want to generate a project reference. Else, generate a regular reference directly to the file for the configuration. 4. You can use file(GENERATE) to make configuration-specific files that list the references for each configuration. These can then be 'ed into the main csproj file. This lets you use generator expressions if you need to when determining the path for your reference. 5. If generating a project reference to a C++ project, you can use $/../ref.vc(x)proj to get to the project file. If the project reference is to another C# project you can use the undocumented EXTERNAL_MSPROJECT target property. If it's a non-project reference then you have to provide a which can be done with $ for C++ references and a custom property you'll have to maintain for C# project references. 6. Don't forget to call CMake add_dependencies() as well. Best regards, James Johnston -- 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] on cmake supporting one arch per project (from CMake IR)
> -Original Message- > From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Greg Marr > Sent: Wednesday, August 05, 2015 18:42 > To: Raymond Wan; Scott Aron Bloom > Cc: cmake@cmake.org > Subject: Re: [CMake] on cmake supporting one arch per project (from > CMake IR) > > > Gilles Khouzam from Microsoft has created an experimental fork, current as > of 3.2.1, that adds this support. > https://github.com/Microsoft/CMake/tree/feature/MSMultiPlatform > > Adding experimental MultiPlatform support to CMake for Windows and VS > 2012 and above. > > By setting the CMAKE_VS_EFFECTIVE_PLATFORMS variable, the user is able > to specify that multiple platforms should be produced for the same project. > > The supported platforms are Win32, ARM and x64 (not applicable to > Windows Phone) and should be specified as a delimited string > Win32;ARM;x64 for example. I read this and also glanced through the patch (look for commit ID 065bdceb0fbe5253b229faa843fce6b1c271f047 in his repo). It feels a little goofy and too VS-centric to me. How should existing end-user code like this be handled? if(MSVC90 AND NOT CMAKE_CL_64) # set 32-bit VC2008 flags set(CMAKE_CXX_FLAGS ) # snip elseif(MSVC90 AND CMAKE_CL_64) # set some 64-bit VC2008 flags set(CMAKE_CXX_FLAGS ) # snip endif() Well, it seems like you would need platform-specific CXX_FLAGS variables, in addition to the configuration-specific CXX_FLAGS variables already offered. So you'd need a lot new CMake variables for the compiler, linker, etc. Ideally you'd want to figure out how to do this without completely breaking every piece of user code that previously ever touched those variables. While you're at it, you'd want platform-specific variables containing platform-specific paths to each compiler. (e.g. path to 32-bit cl.exe, path to 64-bit cl.exe.) Of course, that opens the door to mixing VC++ and non-VC++ compilers in the same CMake project... Also, the meaning of variables like "MSVC90" or even "CMAKE_CL_64" change: previously CMAKE_CL_64 meant "building for 64-bit" whereas maybe now it means "you may or may not be building for 64-bit" ??? What is CMAKE_CL_64 supposed to do if CMAKE_VS_EFFECTIVE_PLATFORMS is set to Win32;x64? Also, you're still limited to VS generator in his patch, as evidenced by "VS" in "CMAKE_VS_EFFECTIVE_PLATFORMS". I guess that's all fine & well as far as Microsoft's concerned. What if I want to build multi-platforms with the Ninja generator? GNU Make generator? Multi-platforms on Linux? Mac? (Personally I dislike the VS generator / MSBuild on Windows for big builds because the parallelization in MSBuild and cl.exe isn't coordinated, leading to significant over/under-subscription problems that can be avoided with any other generator on Windows.) I'm not making this up, if CMake supported multi-platform building, I would be needing/wanting to specify multiple platforms for the project I'm working on right now: (1) VC++ 32-bit, (2) VC++ 64-bit, (3) GCC cross-compiler, (4) C++ Builder. Some targets would be built for multiple platforms; others would be built for only one of those four platforms. I have annoying requirements that multi-platform could help with like: the cross-compiler requires a custom build step/tool that is built using Visual Studio. Very flexible multi-platform can/should be "easy" for the makefile generators to handle. And the VS generator can handle #1 and #2 fine enough but what if I want it to generate a CMake project containing the GCC/BCC32 targets, for example? How the heck does that work? And what if I want multiple VC++ versions in my platform list - say, VC2008 and VS2013? (After all, I could point to differing versions of cl.exe with my platform-specific COMPILER variables). Again that's something that multi-platform makefile generators can/should handle "easily" but what if the VS generator is asked to generate for VC2008 and VC2013 platforms? Right now the VS generators have it easy - they only have one cl.exe version to contend with (and it's guaranteed to be a cl.exe to begin with). I guess you could have the Ninja/makefile generators happily generate true multi-platform stuff while have the VS generator just croak, but then what if I want to use the VS IDE for my VC++ targets? It would be awesome if CMake could support multi-platform - it could really simplify things for me (as now I am working on a superbuild that iterates through all the above platforms) - but I'd rather see it in a form that is baked into the core of CMake, rather than something VS-specific hacked onto the VS generator that I feel won't interact well with anything non-VS. Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic an
Re: [CMake] ninja under windows
> -Original Message- > From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Gonzalo > Garramuño > Sent: Monday, August 03, 2015 17:23 > To: cmake@cmake.org > Subject: [CMake] ninja under windows > > I compiled Ninja on cygwin from git. That now works fine it seems. > I am trying to compile for msvc. However, when cmake runs, I get: > I wouldn't even go there... I would recommend: * Do not build anything requiring native Windows build tools from Cygwin - for example, don't call Visual C++ compiler from Cygwin. * Consider not build anything requiring native Windows build tools from MSYS/MSYS2, like Visual C++ compiler, since MSYS/MSYS2 is a fork of Cygwin. (Unless MSYS/MSYS2 maintainers patch Cygwin to resolve the problems, which you'd better research before going there.) It sounds drastic but I can tell you from experience that eventually you'll run into problems and you may be on your own. The big reason I have run into is that Cygwin's handling of stdin/out/err pipes differs from how most Windows programs (i.e. programs based on Visual C++ runtime, or based on .NET Framework) handle the pipes. They do this for POSIX compatibility reasons, I'd guess. And the Cygwin maintainers in the past have shown limited interest in being compatible with non-Cygwin programs. The end result is you end up with things like a basic/simple .NET Framework 4.0 program not working right if called from Cygwin, for example. If you want to forge ahead, I can offer two suggestions that seem to mitigate the problems - today anyway: * Set CYGWIN environment variable to contain pipe_byte. This is very important but I forget the specifics why, other than non-Cygwin programs break if this isn't set. (Search the Cygwin mailing lists for my posts on the issue). * Make a custom build of Cygwin and then set CYGWIN environment variable to contain pipe_nooverlap (a flag I added). This is also very important because if you don't, .NET Framework 4.0 apps and potentially other programs called from Cygwin will break. I submitted a patch to Cygwin maintainers but they rejected it, so you'll have to build Cygwin yourself (and rebuild it every time the maintainers release new Cygwin version). The link to the patch is here: https://cygwin.com/ml/cygwin-patches/2013-q4/msg00020/pipepatch Setting these flags maybe breaks some POSIX compatibility but in practice, I have had zero problems with common Cygwin programs (bash, coreutils). Since proper interaction with non-Cygwin programs now requires you to make a custom build of Cygwin - a big hassle - I suggest don't even go there, and keep Cygwin (and its MSYS/MSYS2) derivatives out of your build system if you require calling native Windows apps (e.g. Visual C++). There are other unrelated considerations if you want a 100% solid build environment, like you should research the (non-)reliability of forking under Cygwin/MSYS/MSYS2. I have to commend the Cygwin developers for making it work in the first place, since Windows provides no forking API. But in the end, to get POSIX working on the Win32 API, I think they are relying on a lot of undocumented Win32 stuff that works in practice but subject to breakage when new versions of Windows come out, etc. > > Is compiling under the microsoft compiler not an option for ninja files ( I can > compile with NMake Makefiles just fine in the same project ). It is and we do it, here is how: 1. Don't build Ninja under Cygwin. IIRC the procedure would be (a) install Python for Windows, (b) go to a Visual C++ command prompt to set up VC++ environment, (c) call Ninja bootstrapper script. 2. Run CMake from a Visual C++ command prompt when you want to use the Ninja generator because Ninja generator will just look for whatever "cl.exe" is in the PATH. At no point does Cygwin enter into the equation. Best regards, James Johnston -- 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] C# support?
> -Original Message- > From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Stuermer, > Michael SP/HZA-ZSEP > Sent: Friday, June 26, 2015 14:47 > To: cmake-develop...@cmake.org; cmake@cmake.org > Subject: [CMake] C# support? > > Hi and sorry for cross-posting this on both lists, > > I checked the mailing list history about the C#/.NET support topic and realized > that the interest in C# support seems to have declined a bit. > > I am right now in the need of good C# support and adding external project > files is not that much of an option to me. So I started hacking away > everything that is needed for .csproj generation and support of mixed > managed/unmanaged targets. Not yet done, but there is a light at the end of > the tunnel. > > Now the question: is there any real interest at all in this feature? Does it have > a realistic chance to be accepted for upstream or will I have to maintain my > own fork of CMake? > Well, I have only just recently started using CMake. So I am not speaking from a great deal of experience. But I am currently converting over a bunch of stuff into a set of CMake projects. (must be multiple CMake projects built by a superbuild via ExternalProject because we use three different C/C++ compilers and target three different CPU architectures.) Part of that "stuff" involves a mixture of Visual Studio projects involving (1) 100% unmanaged C++ code: this is the easy stuff to move to CMake, (2) C++/CLI mixed mode projects, (3) C# projects that consume the mixed mode C++/CLI projects. I have yet to start working on that part of the CMake migration, but I'm not looking forward to figuring out how to make the C# projects consume the build output from the C++/CLI projects and still have the Visual C# projects be easy to add/remove files from. All these particular projects are targeting Visual Studio 2008 32-bit, so it *ought* be possible to use them all from one single CMake build tree & one single Visual Studio solution... I have seen include_external_msproject CMake command: http://www.cmake.org/cmake/help/v3.3/command/include_external_msproject.html But it's not clear to me how I'd make the C# project depend on other CMake targets (i.e. the mixed mode C++ projects). The best I've thought of would be to use configure_file to modify the project to substitute the compiled C++ DLLs in the references section of the project. But then it will be a pain to modify the original C# projects in SOURCE_DIR. And also, the C# project normally has relative paths, so if it gets configure_file'd into BINARY_DIR all the source code paths will break. I guess all the above is to say, I'm interested in that feature. But I may be too much of a newbie at CMake to say whether that is a good "CMake way" of doing things. I still need to experiment with the above command, and read up on old mailing list messages on the subject. But it seems to me the logical way for supporting C# would be: (1) it becomes a first-class language that can be mentioned in the project() command, (2) therefore, all the generators can use it, so you aren't restricted to Visual Studio generator (I like the Ninja generator because it's faster than Visual Studio), (3) Visual Studio generator would emit a solution containing generated VC++/VC# projects. Anything else feels like a bit of a hack to me. But #1 thru #3 sounds like a lot of work though... Also, C# doesn't compile to object files - does CMake currently support the concept of a language that doesn't require separate compiling/linking steps? Best regards, James Johnston -- 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] Ninja race condition compiling VTK with Borland bcc32 compiler
RA~2\Borland\CBUILD~1\Bin\bcc32.exe -tWR -tW- -tWD @<< -e..\..\bin\vtkzlib.dll -tWM -lS:1048576 -lSc:4098 -lH:1048576 -lHc:8192 -v import32.lib $(vtkzlib_OBJECTS) $(vtkzlib_EXTERNAL_OBJECTS) << implib -c -w ..\..\bin\vtkzlib.lib ..\..\bin\vtkzlib.dll cd C:\Users\JamesJ\Documents\Repositories\SuperRepo\VTK-JOM = For what it's worth, at this time, I think this issue is limited to the linker and not to the single-unit compilation of a CPP file to OBJ file. I ran Process Monitor for a few seconds while VTK was compiling, and it seems that the only file writes to the build tree were either legitimate writes to named intermediate/output files, or else to these problematic files from the linker. Best regards, James Johnston -- 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
