Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation
My solution needs to generate additional target indeed for one pre-generated header, so if all your 1000+ targets will share same precompiled header (given the compiler flags don't change) then you will have just one (single) additional target. It's very rare (not to mention risky) to be able to share a PCH with more than one target, because each target can have its own set of defines/flags and header inclusions, so we'd really end up with additional 1000+ targets. BTW, please note that the most recent test is still https://github.com/nanoant/CMakePCHCompiler/issues/1#issuecomment-77003296 If CMake will support PCH natively I don't see any reason it will need extra target, yet obviously there will be extra (Ninja) compiler rule for PCH. That's far better than extra targets. -- 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-developers
Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation
Two requests please: * The option to use existing headers instead of autogenerated ones. * Implementing PCH support without additional targets. ReactOS already has like 1000+ targets, and we currently use PCH on almost all of them, so imagine if this official implementation doubles our targets number. Regards, Amine. -- 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-developers
Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation
Hi Adam, First of all thank you for working on PCH support, it's something we greatly appreciate at ReactOS, even though right now we're using Peter Kümmel's solution. It didn't make it upstream but it's working nicely for us for quite a while. Does your solution support Ninja generator? I ask because any existing solution based on upstream CMake won't work with the Ninja generator. Peter's solution is the only existing solution we know about. Does your solution support C source files/targets? you mentioned meta C++ compiler so it seems to be C++ centric IIUC. Regards, Amine. -- 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-developers
Re: [cmake-developers] Severe regression caused by #14972 fixes
This will not be done before the freeze for 3.1 on Thursday. Reverting 7243c951 will resolve the problem for ReactOS in out-of-source builds. So, we either revert that or hope Ninja can be fixed to deal with the large dependency lists w/out crashing. In the discussion with Adam, he mentioned (about input files) that CMake can not know that some file will always exist or not, and that it doesn't know files is generated unless someone tells that, *unfortunately some projects don't* Reverting this change makes more sense, because CMake has always been advertised as being designed for out-of-source builds, and we cannot penalize every single sane CMake user out there simply because some projects do not properly mark their generated input files (in custom commands) as GENERATED. I don't understand why is it okay for the CMake project (at least in ReactOS case) to introduce now a (very) huge list of our codebase *source files* (files that exist in our *repo* and not *generated* nor we can even *assume* they may not exist at some point, because they will *always* exist) simply to solve a problem that is, if some projects do *not* properly use CMake (GENERATED property, adding dependencies properly on commands/target that generate the said input files...etc) we need to do this to keep them working. The extra bloat of generating a very large list of phony rules on *source* files to solve a CMake misuse problem suggests that we're Doing It Wrong. If ninja didn't crash on us, we would probably never find out about this bloat, unless some of us randomly had the idea of diffing the old build log (from CMake 2.8.x) with this new one. -- 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-developers
Re: [cmake-developers] VS10-12 generators deserve much more love
Please note that I already expressed how ReactOS sees the current VS support in CMake: http://public.kitware.com/pipermail/cmake-developers/2013-July/007666.html I welcome and support any effort that allows CMake to generate VS solutions that work as VS users expect them to be. Cheers, Amine. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Patches for Visual Studio multi-CPU architecture project generation and a Windows-Phone-8 generator
Okay, I think we can work with adding the CMAKE_GENERATOR_PLATFORMS variable to specify the list of platforms (what you called CMAKE_MSVC_PLATFORMS). It can be documented as supported only by the WP8 generators for now. If a project or user sets the variable they are responsible for making the build work that way. It won't appear by default or be used by other generators so no one else will be affected. We very much hope that this would help making http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272 a reality at last. However on balance I don’t think adding multi-platform to the general VS toolchain adds any value. For example there’s no point in compiling CMAKE for x64 as it doesn't need to address 4GB RAM and it won't even be possible to compile it for ARM as CMAKE can’t run under Windows 8 RT. Please note that multi platform is the *norm* in VS solutions, not the exception. Any and every real world VS user expects its support. The lack of this support is what doesn't make sense, not the other way around. Regards, Amine. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using multiple toolchains
I just want to express that we (ReactOS) are also a victim of this separation between native and cross compiling CMake invocations, because we depend on some host tools that we must compile natively, in order to use them later on when compiling ReactOS itself. In Windows for example, the native and the cross compiling toolchains can be (and they often are) one and the same, so having this separation is.. interesting. We also use Visual Studio but the CMake generated solution is far from a normal/expected VS solution, because it doesn't make use of VS' support of multiple toolchains in one solution, and the support of host/target toolchains. What you get is two solutions where you must open the host tools (native) one first, compile it, then close it and open the target one (cross compiling) in order to really start compiling anything (the native solution exports the not tools). Being the one who converted ReactOS from rbuild (our own build system) to CMake, when I discovered this problem, I was hoping that it's simply due to my lack of understanding and familiarity with CMake (I knew *nothing* about CMake when I started the experiment in a ReactOS branch), but until today, we're still having two build folders: one for host tools and one for the actual ReactOS. Inspecting the ExternalProject approach not only led to even more complex build scripts and no success in implementing one CMake invocation to get things done (we tried), but also led to going even farther from the expected VS behavior when it comes to multiple toolchains. As you can see, we really feel the pain and the need for a proper, CMake based, VS aware approach to multiple toolchains, and I wanted you to know that we really welcome such a long overdue effort ! Cheers, Amine. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Fwd: Re: ReactOS: Important filed bug reports went to backlog en masse
Hello, I missed to reply to all, in my reply, and I only found out after receiving no reply from David even though he's been replying in the list (so this must be some policy that I'm not aware of). Here goes: Original Message Subject: Re: [cmake-developers] ReactOS: Important filed bug reports went to backlog en masse Date: Mon, 13 Aug 2012 15:30:34 +0100 From: Amine Khaldi amine.kha...@reactos.org To: David Cole david.c...@kitware.com Hi David, I certainly did not mean to offend anyone with my en masse move of issues to 'backlog' -- thanks for speaking up. I would like to make sure that you guys can continue to use CMake for ReactOS. Thank you, we were surprised to see the long awaited bugs simply disappear, we thought there are just more important things that you guys are working on, so we were patient. I've got to run right now, but I will reply again tomorrow when I have some more time. Do you have time for a quick phone call or Google+ hangout this week sometime, so I can understand better what your issues are? (And why nobody adopted them when they appeared on the mailing list in the form of your bug reports...) Due to my net speed, I'm afraid the best we can do is a realtime text conversation, so if irc or any other IM is an option, please let me know and I'll be ready. Thank you, Amine. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fwd: Re: ReactOS: Important filed bug reports went to backlog en masse
Even better: http://webchat.freenode.net/ would require just a browser ;) Otherwise this email is a google account too, so if that upper link doesn't work (I'm AmineKhaldi on #reactos) then we can easily use google plus chat. Regards, Amine. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] ReactOS: Important filed bug reports went to backlog en masse
Hello folks, I would like to mention that many (if not all) the bugs coming from us (ReactOS) got into backlog. We're an operating system project, we try to file bug report only for issues that block us, so we do not tend to file trivial bugs. It would be great if the CMake folks tried to pay the attention that our issues deserve.. after all, we started using CMake because we read many positive reviews about the excellent support. Unfortunately, we're not able to use the VS generators due to the lack of support for ASM preprocessed files. We're not able to pass flags to C/C++ source files without affecting the rc (resource) files. We're forced to do many ugly workarounds for the latter, and we found no solution for the former, and these are just examples. All these mentioned issues got into the backlog, so basically we're left off, without any help to get them solved. I'm writing this hopefully as a call to the CMake folks/community to address our issues, that we've been waiting release after release to get them fixed, only to find out that they ended up in backlog now. I'm writing this in the hopes of finding a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing. Regards, Amine. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
One of my last changes was to replaces back slashes with slashes exactly because of \../../ problems. Have you used cl and recent next? With cl and recent next: * Our host tools (the host-tools folder) basically get rebuilt everytime you run ninja, and -d explain suggests x86 is dirty and /Windows Kits/8.0/include/shared/sal.h is dirty...etc because we end up with entries like C:/Program\ Files\ (x86)/Windows\ Kits/8.0/include/shared/ConcurrencySal.h and C:/Program\ Files\ (x86)/Windows\ Kits/8.0/include/shared/sal.h in the .d files. * As to ros itself, ntoskrnl produces a correct ninja: no work to do. when you rebuild and also tracks this E:/reactos/ntoskrnl/include/../mm/ARM3/miarm.h correctly if you alter it (leading to the recompilation of the dependent files). * Here we also lack the dependency tracking of the includes inside rc files. With gcc (windows) and recent next: * Our host tools (the host-tools folder) basically get rebuilt everytime you run ninja, and -d explain suggests psdk/guiddef.h is dirty (because of e:\reactos\include\host/../psdk/guiddef.h in the .d files) and reactos/wine/rpcfc.h is dirty (because of e:\reactos\include\host/wine/../../reactos/wine/rpcfc.h)... etc. * As to ros itself, ntoskrnl gets recompiled everytime, because of entries like e:\reactos\ntoskrnl\include/../kdbg/kdb.h and e:\reactos\ntoskrnl\include/../mm/ARM3/miarm.h... etc. Regards, Amine. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
The gcc build issues are all fixed. Thanks ! The cl scenario for host-tools remains, I'm still getting entries like C:/Program\ Files\ (x86)/Windows\ Kits/8.0/include/shared/ConcurrencySal.h and C:/Program\ Files\ (x86)/Windows\ Kits/8.0/include/shared/sal.h Thank you for looking into the rc handling too ;) Regards, Amine. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
Have you also rebuild cmcldeps? That was it. My VS generated solution didn't have cmcldeps listed among the modules, so I only rebuilt cmake. I confirm it works. Excellent work Peter, thanks. Regards, Amine. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
Hi, I just tested this with ReactOS and the results are really promising ! Thank you Peter for working on this. One thing I noticed is the lack of dependency tracking for the resource files (*.rc, they are compiled with rc and not cl). If you #include a file in an .rc and then alter that included file, nothing will happen. We had the same problem with the gcc builds, but since windres is more flexible re. the preprocessor pass, I introduced this line into our cmake files: set(CMAKE_DEPFILE_FLAGS_RC --preprocessor \CMAKE_C_COMPILER -E -xc-header -MMD -MF DEPFILE -MT OBJECT\) I wonder what would be the solution in order to track such dependencies with the msvc toolchain. Regards, Amine. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
Another thing I noticed while testing ReactOS is that we end up with entries like e:\reactos\ntoskrnl\include/../mm/ARM3/miarm.h (for example) in the .d files, and this triggers recompiles. If this /../ construct is eliminated (not that it's practically possible, I did it just for testing) the dependency works fine. Regards, Amine. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja: Regressions re. def file handling with MSVC
CMake recognizes the .def extension automatically. Don't mark it with the EXTERNAL_OBJECT property because that tells CMake to treat it as an external .obj file. If you remove that mark do things work correctly? I just removed that property from the gcc build. Now with both MSVC and gcc builds I get ninja: ERROR: 'foo.def', needed by 'bar.dll', missing and no known rule to make it. If I revert the commit I mentioned before, it works and the def file is handled correctly. Regards, Amine. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja: Regressions re. def file handling with MSVC
CMake has the ModuleDefinition test covering .def handling: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/ModuleDefinition/CMakeLists.txt;hb=a2514f15 and it passes on our nightly testing both before and after the change in question. Your use case must be different from what that test covers. Can you provide a minimal source tarball to reproduce the problem? Our use case is slightly different, we generate those def files and add them to the source list. Please take a look at http://git.reactos.org/?p=reactos.git;a=blob;f=reactos/cmake/gcc.cmake;h=31d71b28c9e5156caf75efc2d45b16a23bb503d9;hb=HEAD#l243 for example. Regards, Amine. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja: Regressions re. def file handling with MSVC
Thanks. I've extended the ModuleDefinition test to cover that: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=89987c21 and fixed the Ninja generator: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d2c764ad Ironically commit a2514f15 would have been a smaller patch had I used the approach in commit d2c764ad in the first place ;) Thanks for the detailed report and bisect work. You're quite welcome, thank you for fixing this issue promptly :) BTW, you should still avoid marking .def files as EXTERNAL_OBJECT. Do you know why that mark was added in the first place? Committed in r56321, thanks. This got added at first into the import lib rule here: http://git.reactos.org/?p=reactos.git;a=blob;f=reactos/cmake/gcc.cmake;h=31d71b28c9e5156caf75efc2d45b16a23bb503d9;hb=HEAD#l254 which seems to indicate the object needed for the IMPLIB static library (this is a custom linker language, used here for our convenience). Removing it in this case will lead to some errors. BTW, please feel free to examine our scripts, we gladly accept any feedback. I like how they revealed a missing testcase today for example ;) Regards, Amine. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Ninja: Regressions re. def file handling with MSVC
Hi, Please note that commit a2514f15fae34abb6f29dddf6f5cfe8b171a8035 broke the handling of def files when using MSVC. We get errors like: ninja: ERROR: 'reactos\base\applications\kbswitch\kbsdll\kbsdll.def', needed by 'base\applications\kbswitch\kbsdll\kbsdll.dll', missing and no known rule to make it I found this revision by doing a bisect, I hope this will help solving this issue. In the gcc build we declare this generated def as an external object, but if I do the same with the MSVC build, the def file gets inserted into the link command twice: * The first one directly, i.e. link.exe /nologo the def file here the rest of the link command * The second time, it's passed using a /DEF:the def file Needless to say, the first insertion is spurious and invalid, and it triggers def file : fatal error LNK1107: invalid or corrupt file: cannot read at 0x3BBD. Regards, Amine. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
