Re: [CMake] Secret precompiled header support?
On 5/17/2012 12:50 PM, Robert Dailey wrote: Normally when you encounter professional software (that is, software that you pay for, that is generally well designed and maintained by a single entity), it has a consistent feel. Open source naturally can feel inconsistent because of the large number of contributions, which sometimes don't follow the same implementation patterns. I hope that clarifies what I meant. An example, as I had stated, is general compiler flag support. For example, we have convenience methods for includes and preprocessor definitions, but PCH and warning levels does not have such a thing. I don't think this is an open source vs closed source thing either. I think it is more of a cross platform thing. I have used plenty of software that you pay for that is missing features or very buggy expect there is no way to fix it yourself... Not that I am saying CMake is buggy and missing features.. :) What you are seeing in CMake is more a lack of cross platform support for PCH, and consistent warning levels in C++ compilers. These things just are not consistent across various compilers and operating systems out there. So, in those cases CMake has to step up and create a consistent API, which of course is much harder, and will have holes because various compiler won't support it. For example if we created some nice functions to do PCH, they would only work on a small percentage of the supported compilers. Coming up with a mapping of warning flags is just as challenging. However, include flags and preprocessor definitions are standard and required for a C++ compiler to work. PCH and warning levels are not required to build C++, so those features are missing and vary in implementation across compilers. The idea behind CMake is to provide as consistent a cross platform interface to the build as possible. However, we allow access to platform specific flags and settings so that projects that need to work on a specific platform can do so. Since, as you say I am only a Windows developer, you should be able to put the windows specific PCH stuff into your project and it won't be too much of an issue for your project. All that said, it would be nice to have a better interface for PCH support that would work when it was available. However, to date it has not been a high priority. So, not having these features has IMO little to do with CMake being professional or consistent, or Kitware taking CMake seriously, but rather with the difficulty of implementation and lack of standardization in C++ compilers. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Secret precompiled header support?
On Fri, May 18, 2012 at 9:51 AM, Bill Hoffman bill.hoff...@kitware.comwrote: On 5/17/2012 12:50 PM, Robert Dailey wrote: Normally when you encounter professional software (that is, software that you pay for, that is generally well designed and maintained by a single entity), it has a consistent feel. Open source naturally can feel inconsistent because of the large number of contributions, which sometimes don't follow the same implementation patterns. I hope that clarifies what I meant. An example, as I had stated, is general compiler flag support. For example, we have convenience methods for includes and preprocessor definitions, but PCH and warning levels does not have such a thing. I don't think this is an open source vs closed source thing either. I think it is more of a cross platform thing. I have used plenty of software that you pay for that is missing features or very buggy expect there is no way to fix it yourself... Not that I am saying CMake is buggy and missing features.. :) What you are seeing in CMake is more a lack of cross platform support for PCH, and consistent warning levels in C++ compilers. These things just are not consistent across various compilers and operating systems out there. So, in those cases CMake has to step up and create a consistent API, which of course is much harder, and will have holes because various compiler won't support it. For example if we created some nice functions to do PCH, they would only work on a small percentage of the supported compilers. Coming up with a mapping of warning flags is just as challenging. However, include flags and preprocessor definitions are standard and required for a C++ compiler to work. PCH and warning levels are not required to build C++, so those features are missing and vary in implementation across compilers. The idea behind CMake is to provide as consistent a cross platform interface to the build as possible. However, we allow access to platform specific flags and settings so that projects that need to work on a specific platform can do so. Since, as you say I am only a Windows developer, you should be able to put the windows specific PCH stuff into your project and it won't be too much of an issue for your project. All that said, it would be nice to have a better interface for PCH support that would work when it was available. However, to date it has not been a high priority. So, not having these features has IMO little to do with CMake being professional or consistent, or Kitware taking CMake seriously, but rather with the difficulty of implementation and lack of standardization in C++ compilers. I certainly agree with all of your points but consider this. Even though PCH support may not exist on every compiler, every company that wants to add PCH support to CMake through scripting logic is essentially doing the same work over and over again. Everybody is going to do the same things: 1. Restrict the functionality to MSVC only via conditional branching 2. Call the same CMake commands to add the same compiler flag with the same parameters Just because every compiler doesn't support it doesn't mean CMake can't provide some way to eliminate the boilerplate. If we want to use PCH through CMake, there is certain logic that must exist. It's really just a question of WHERE that should exist: In CMake C++ code or in CMake as a script. What do we do if PCH support isn't provided by a compiler, but we have enabled it in our scripts? There are several things you can do, but what I commonly do is just ignore the request. For example, for all platforms I may invoke my custom function to enable PCH, but on the platforms that don't support it, it's just going to make sure that those files get compiled. Even if you don't enable PCH or can't use it, the PCH header file is still included in all CPP files that need includes from it, so the code will still compile. In this specific case, ignoring the request still works, and the user doesn't have to worry about the lack of the feature resulting in the build failing. You know all of this but the main point I wanted to make is that even though CMake can't guarantee PCH support on all platforms, it's still adding value by eliminating boilerplate. People won't be redundantly implementing and re-testing the same complex logic to add the feature in a modular way. Maybe a good middle ground would be to have a CMake built in module that provides convenience functions for operations like this. That way, CMake C++ code isn't changing, but we still give the users a subset of functionality to work with. Just a thought! -- 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] Secret precompiled header support?
On 5/18/2012 12:51 PM, Robert Dailey wrote: I certainly agree with all of your points but consider this. Even though PCH support may not exist on every compiler, every company that wants to add PCH support to CMake through scripting logic is essentially doing the same work over and over again. Everybody is going to do the same things: 1. Restrict the functionality to MSVC only via conditional branching 2. Call the same CMake commands to add the same compiler flag with the same parameters Just because every compiler doesn't support it doesn't mean CMake can't provide some way to eliminate the boilerplate. If we want to use PCH through CMake, there is certain logic that must exist. It's really just a question of WHERE that should exist: In CMake C++ code or in CMake as a script. What do we do if PCH support isn't provided by a compiler, but we have enabled it in our scripts? There are several things you can do, but what I commonly do is just ignore the request. For example, for all platforms I may invoke my custom function to enable PCH, but on the platforms that don't support it, it's just going to make sure that those files get compiled. Even if you don't enable PCH or can't use it, the PCH header file is still included in all CPP files that need includes from it, so the code will still compile. In this specific case, ignoring the request still works, and the user doesn't have to worry about the lack of the feature resulting in the build failing. You know all of this but the main point I wanted to make is that even though CMake can't guarantee PCH support on all platforms, it's still adding value by eliminating boilerplate. People won't be redundantly implementing and re-testing the same complex logic to add the feature in a modular way. Maybe a good middle ground would be to have a CMake built in module that provides convenience functions for operations like this. That way, CMake C++ code isn't changing, but we still give the users a subset of functionality to work with. Just a thought! I agree, I hate to see code duplication. We do have a test to make sure it is possible that is run each night: Tests/PrecompiledHeader I have never used it, so I am not sure how hard it is. I am thinking maybe the thing to do is create a module for each compiler that we add support for PCH. Something like Modules/MSVCPCH.cmake. Since it is so compiler specific. Then the implementation would be in cmake code in a module and it will be clear that it is for one compiler. Perhaps you could generalize what you have already done into a module like this that could be included in CMake? -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Secret precompiled header support?
On Fri, May 18, 2012 at 12:07 PM, Bill Hoffman bill.hoff...@kitware.comwrote: On 5/18/2012 12:51 PM, Robert Dailey wrote: I certainly agree with all of your points but consider this. Even though PCH support may not exist on every compiler, every company that wants to add PCH support to CMake through scripting logic is essentially doing the same work over and over again. Everybody is going to do the same things: 1. Restrict the functionality to MSVC only via conditional branching 2. Call the same CMake commands to add the same compiler flag with the same parameters Just because every compiler doesn't support it doesn't mean CMake can't provide some way to eliminate the boilerplate. If we want to use PCH through CMake, there is certain logic that must exist. It's really just a question of WHERE that should exist: In CMake C++ code or in CMake as a script. What do we do if PCH support isn't provided by a compiler, but we have enabled it in our scripts? There are several things you can do, but what I commonly do is just ignore the request. For example, for all platforms I may invoke my custom function to enable PCH, but on the platforms that don't support it, it's just going to make sure that those files get compiled. Even if you don't enable PCH or can't use it, the PCH header file is still included in all CPP files that need includes from it, so the code will still compile. In this specific case, ignoring the request still works, and the user doesn't have to worry about the lack of the feature resulting in the build failing. You know all of this but the main point I wanted to make is that even though CMake can't guarantee PCH support on all platforms, it's still adding value by eliminating boilerplate. People won't be redundantly implementing and re-testing the same complex logic to add the feature in a modular way. Maybe a good middle ground would be to have a CMake built in module that provides convenience functions for operations like this. That way, CMake C++ code isn't changing, but we still give the users a subset of functionality to work with. Just a thought! I agree, I hate to see code duplication. We do have a test to make sure it is possible that is run each night: Tests/PrecompiledHeader I have never used it, so I am not sure how hard it is. I am thinking maybe the thing to do is create a module for each compiler that we add support for PCH. Something like Modules/MSVCPCH.cmake. Since it is so compiler specific. Then the implementation would be in cmake code in a module and it will be clear that it is for one compiler. Perhaps you could generalize what you have already done into a module like this that could be included in CMake? I'd be more than happy to do that, however my setup is a little different from what you're suggesting. I basically have something like this (pseudo code): function( precompiled_headers ) if( MSVC ) elseif( GCC ) else() # Not supported endif() endfunction() If you are wanting to split it out into separate modules, the logic above would be the responsibility of the client. In other words, CMake wouldn't help the user choose the right CMake PCH module depending on their target compiler. Am I misunderstanding your idea? -- 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] Secret precompiled header support?
Hey Bill, First of all apologies if I have offended anyone, my goal wasn't to disrespect CMake or anyone's efforts they put into it. Perhaps I made a poor choice of words. What I was trying to convey with my use of the word professional was to say that there are areas that seem inconsistent or odd to use, and by making those more consistent it seems more professional. Perhaps instead of saying professional, I should just say consistent :) Normally when you encounter professional software (that is, software that you pay for, that is generally well designed and maintained by a single entity), it has a consistent feel. Open source naturally can feel inconsistent because of the large number of contributions, which sometimes don't follow the same implementation patterns. I hope that clarifies what I meant. An example, as I had stated, is general compiler flag support. For example, we have convenience methods for includes and preprocessor definitions, but PCH and warning levels does not have such a thing. Outside of the mailing list, I am trying to sell the company I'm working for on using CMake. Every day, all I do is say great things about CMake and I even mention you and David personally to people I work with and speak highly of Kitware. So trust me, I really do talk a lot more about the positives than the negatives. However, it's not as useful to start a post here on the mailing list about the great things that have already been done. It's nice to show appreciation but such a discussion isn't as productive as discussing what to do next or what to improve. After all, I see the mailing list as a place to get help and to discuss future work. The discussion has gotten quite off track. I just wanted to let everyone know that never during the discussion was I upset or intended to come off as hostile, that's the tricky thing about text. You can't really know what the person is really feeling or saying :) On a more relevant and productive note, I'd love to help add new commands or whatever to help make supporting different compiler features more compiler-agnostic, but there are a couple of issues: 1. I am only a Windows developer, so I can only really provide solutions targeting MSVC. Such a patch would not be useful as I'd have to handle a wide range of compilers such as ARM and GCC. 2. Creating a new command for every single compiler flag or feature can get out of control easily and quickly become unmaintainable and messy to use and document. I think this is where the Boost modularization discussion becomes useful, because they have outlined in detail some great ideas to creating a uniform sort of meta-language to supporting a finite number of compiler options without adding bloat to the commands list. If you haven't had a chance to look this over, it would make for a great read, especially for the more experienced CMake developers like you and David. It's a tough issue to tackle but at least the majority of people here recognize improvement is in order. The problem is, it's a tall order. On Wed, May 16, 2012 at 8:47 PM, Bill Hoffman bill.hoff...@kitware.comwrote: On 5/16/2012 3:49 PM, Robert Dailey wrote: involved with CMake will help push Kitware to realize how serious people are taking their products and maybe they'll make a move to professionalize them. So, I do take offense to this language. Kitware does take CMake seriously and we are always moving to make it better. However, since it is an open source project, we do not get any direct revenue from CMake. We do of course receive revenue from companies and agencies willing to hire us to implement features or develop CMake build systems for them. If your company wants generic pre-compiled header support, we would love for you to hire Kitware to implement it. If you are working on an open source project and you would like to contribute pch support that would be great as well. I think the fact that you are able to do what you need to do, even with a bit of extra work speaks to the professionalism and flexibility of CMake. If you were unable to create a working build system that supported PCH and the other features you found missing in CMake, that would be a failure of CMake. If at the moment CMake does not have an elegant way to achieve a particular goal, I don't think that makes it an unprofessional software tool. I was using the word serious here as more of a verb, not an adjective. I'm saying that boost considering CMake is an indication of how people are taking CMake seriously. In other words, popular communities are depending on CMake (or gathering interest in) which makes CMake a tool taken more seriously. Understand now? Not really... KDE (one of the world's largest open source projects) adopted CMake in 2006, and they have been a great community to work with. We have, when KDE goals have intersected with some of our paying customers, been able to implement
Re: [CMake] Secret precompiled header support?
On Tue, May 15, 2012 at 1:14 PM, Eric Noulard eric.noul...@gmail.comwrote: 2012/5/15 Robert Dailey rcdailey.li...@gmail.com: On Tue, May 15, 2012 at 7:34 AM, Dave Abrahams d...@boostpro.com wrote: For me, no. I'm trying to make a transition to CMake in a community where this is being seen as a problematic limitation. I actually was reading over the boost modularization discussion, but I didn't spend enough time there to understand what this whole process is for. I'm assuming this is being setup so users can download pieces of boost individually and only use the parts they want. I'm glad that Boost is making a real effort to use CMake. I think such an influential community being involved with CMake will help push Kitware to realize how serious people are taking their products and maybe they'll make a move to professionalize them. I could not resist a troll like that. No offense but saying that CMake has to address such and such limitation/weirdiness seems ok to me, but going down to infer that no serious people do currently use CMake is a little hard to read... ...and... I'm not speaking for myself since I'm not considering myself as a serious guy anyway :-] All that said I can witness that serious patches are more than usually welcome :-) Please make sure you properly understand what I'm saying before you call me a troll. I was using the word serious here as more of a verb, not an adjective. I'm saying that boost considering CMake is an indication of how people are taking CMake seriously. In other words, popular communities are depending on CMake (or gathering interest in) which makes CMake a tool taken more seriously. Understand now? -- 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] Secret precompiled header support?
On Tue, May 15, 2012 at 3:00 PM, Dave Abrahams d...@boostpro.com wrote: on Tue May 15 2012, Robert Dailey rcdailey.lists-AT-gmail.com wrote: On Tue, May 15, 2012 at 7:34 AM, Dave Abrahams d...@boostpro.com wrote: on Mon May 14 2012, Robert Dailey rcdailey.lists-Re5JQEeQqe8AvxtiuMwx3w-AT-public.gmane.org wrote: Is improvement desired in this area? By me, yes. By this, do you mean, you've taken an initiative to fix this yourself? If so, let me know if I can help out with anything. No, it means I desire an improvement. Is the current implementation really satisfactory? For me, no. I'm trying to make a transition to CMake in a community where this is being seen as a problematic limitation. I actually was reading over the boost modularization discussion, but I didn't spend enough time there to understand what this whole process is for. I'm assuming this is being setup so users can download pieces of boost individually and only use the parts they want. I'm glad that Boost is making a real effort to use CMake. I think such an influential community being involved with CMake will help push Kitware to realize how serious people are taking their products and maybe they'll make a move to professionalize them. By that I mean, CMake is a great tool but very inconsistent and somewhat messy and obscure in a lot of areas. I have to say that I'm thoroughly impressed that CMake is as clear as it is, and also impressed with the community's (and Kitware's) responsiveness to requests for clarification. Major work needs to be done here to polish everything and make it feel organized and professional. You can claim portability all day but you have to do it right. Right now I feel CMake is 60% there. I say that because that 40% I had to implement via CMake scripts over the course of several months, resulting in a couple thousand lines of CMake code (to handle transitive include dependencies, compiler-agnostic features such as PCH and warning levels, private/public include directories, and other things). Maybe you'd like to contribute some of those upstream to CMake (or, if not, at least to the Ryppl project)? As much as I'd love to contribute, I quite simply just do not have the time. It's typical of open source / linux people to rashly and sometimes harshly demand people do the work themselves, or stfu. It sounds like that's where this conversation is headed. I can contribute as much as my opinion and suggestions (as a general end-user of the product), nothing more. I have time for small fixes and whatnot every now and then, but by no means can I dedicate so much time to the product. I don't feel like actual work needs to be done in order to justify sharing my opinions on CMake. I appreciate CMake greatly, after all, I can't imagine where I'd be right now without it. Even having half of what CMake is today would be enough for me. Things can always be better, that's the main point I'm making. CMake is functional right now for my day to day needs (for the most part), but a lot of the changes I mentioned can help improve usability and maintainability of the build systems designed around CMake. The goal for CMake certainly isn't just functional, I hope. -- 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] Secret precompiled header support?
2012/5/16 Robert Dailey rcdailey.li...@gmail.com: On Tue, May 15, 2012 at 1:14 PM, Eric Noulard eric.noul...@gmail.com I'm assuming this is being setup so users can download pieces of boost individually and only use the parts they want. I'm glad that Boost is making a real effort to use CMake. I think such an influential community being involved with CMake will help push Kitware to realize how serious people are taking their products and maybe they'll make a move to professionalize them. I could not resist a troll like that. No offense but saying that CMake has to address such and such limitation/weirdiness seems ok to me, but going down to infer that no serious people do currently use CMake is a little hard to read... ...and... I'm not speaking for myself since I'm not considering myself as a serious guy anyway :-] All that said I can witness that serious patches are more than usually welcome :-) Please make sure you properly understand what I'm saying before you call me a troll. I wasn't calling you a troll at all. I was considering what you *said* in your message was a troll. I was using the word serious here as more of a verb, not an adjective. I'm saying that boost considering CMake is an indication of how people are taking CMake seriously. In other words, popular communities are depending on CMake (or gathering interest in) which makes CMake a tool taken more seriously. Understand now? Sure and I'm pretty sure CMake community and developers in the first place try hard to make CMake as robust and as consistent as they can, i.e. making it a serious tool in many sense. Please don't be mad at me, as you probably altready guessed I'm not a native english speaker so misunderstanding is definitely possible on my side. You may always consider my remark as non-aggressive, for sure. Stopping here because I'm already too off topic. Sorry for the noise. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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] Secret precompiled header support?
On Wed, May 16, 2012 at 3:20 PM, Eric Noulard eric.noul...@gmail.comwrote: Sure and I'm pretty sure CMake community and developers in the first place try hard to make CMake as robust and as consistent as they can, i.e. making it a serious tool in many sense. Please don't be mad at me, as you probably altready guessed I'm not a native english speaker so misunderstanding is definitely possible on my side. You may always consider my remark as non-aggressive, for sure. Stopping here because I'm already too off topic. Sorry for the noise. I'm not mad at all, just wanted to be clear :-) -- 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] Secret precompiled header support?
On 5/16/2012 3:49 PM, Robert Dailey wrote: involved with CMake will help push Kitware to realize how serious people are taking their products and maybe they'll make a move to professionalize them. So, I do take offense to this language. Kitware does take CMake seriously and we are always moving to make it better. However, since it is an open source project, we do not get any direct revenue from CMake. We do of course receive revenue from companies and agencies willing to hire us to implement features or develop CMake build systems for them. If your company wants generic pre-compiled header support, we would love for you to hire Kitware to implement it. If you are working on an open source project and you would like to contribute pch support that would be great as well. I think the fact that you are able to do what you need to do, even with a bit of extra work speaks to the professionalism and flexibility of CMake. If you were unable to create a working build system that supported PCH and the other features you found missing in CMake, that would be a failure of CMake. If at the moment CMake does not have an elegant way to achieve a particular goal, I don't think that makes it an unprofessional software tool. I was using the word serious here as more of a verb, not an adjective. I'm saying that boost considering CMake is an indication of how people are taking CMake seriously. In other words, popular communities are depending on CMake (or gathering interest in) which makes CMake a tool taken more seriously. Understand now? Not really... KDE (one of the world's largest open source projects) adopted CMake in 2006, and they have been a great community to work with. We have, when KDE goals have intersected with some of our paying customers, been able to implement features for them. They have also contributed a ton of code back to the CMake. So, I would love to see Boost use CMake as a build system. I would expect the same type of community interaction that we have had with KDE. Over time, I am sure if PCH headers become a big enough issue for someone they will be implemented in CMake with a cleaner interface. CMake is far from a static project and has plenty of contributors inside and outside of Kitware. Like any software project, there is always more to do. I can say Kitware is committed to shepherding the CMake project and will be developing new features and fixing bugs into the foreseeable future. If Boost adopts CMake, I would welcome the contributions that would come from that community, and I am sure both projects would be better for it in the future. So, I don't think it is fair to judge the CMake project on what it does not do elegantly, but rather to judge it on what it does well. Which, I think is a great deal of very useful cross platform build features allowing very large open and closed source projects to build on a variety of platforms. I am not sure exactly what you were trying to achieve with your email, but it was somewhat of an insult to at least one CMake developer (myself). I and the rest of the CMake team take pride in what we have achieved, and to say that we did not do a professional job, and don't take every user seriously is an insult. If you have suggestions or ideas on how PCHs or any other feature could be implemented in CMake, please bring the discussion to the cmake-developers list. Even if it is not implemented right away, if you have the time to discuss what that implementation would look like, that would be a welcomed contribution. However, lets try to steer this conversation back to the technical issues and away from non-technical issues. I suppose this is enough said, and most likely too much said... :) -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Secret precompiled header support?
on Mon May 14 2012, Robert Dailey rcdailey.lists-Re5JQEeQqe8AvxtiuMwx3w-AT-public.gmane.org wrote: Is improvement desired in this area? By me, yes. Is the current implementation really satisfactory? For me, no. I'm trying to make a transition to CMake in a community where this is being seen as a problematic limitation. -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- 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] Secret precompiled header support?
On Tue, May 15, 2012 at 7:34 AM, Dave Abrahams d...@boostpro.com wrote: on Mon May 14 2012, Robert Dailey rcdailey.lists-Re5JQEeQqe8AvxtiuMwx3w-AT-public.gmane.org wrote: Is improvement desired in this area? By me, yes. By this, do you mean, you've taken an initiative to fix this yourself? If so, let me know if I can help out with anything. Is the current implementation really satisfactory? For me, no. I'm trying to make a transition to CMake in a community where this is being seen as a problematic limitation. I actually was reading over the boost modularization discussion, but I didn't spend enough time there to understand what this whole process is for. I'm assuming this is being setup so users can download pieces of boost individually and only use the parts they want. I'm glad that Boost is making a real effort to use CMake. I think such an influential community being involved with CMake will help push Kitware to realize how serious people are taking their products and maybe they'll make a move to professionalize them. By that I mean, CMake is a great tool but very inconsistent and somewhat messy and obscure in a lot of areas. Major work needs to be done here to polish everything and make it feel organized and professional. You can claim portability all day but you have to do it right. Right now I feel CMake is 60% there. I say that because that 40% I had to implement via CMake scripts over the course of several months, resulting in a couple thousand lines of CMake code (to handle transitive include dependencies, compiler-agnostic features such as PCH and warning levels, private/public include directories, and other things). -- 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] Secret precompiled header support?
Hi, On Tue, May 15, 2012 at 12:00:09PM -0400, cmake-requ...@cmake.org wrote: Date: Tue, 15 May 2012 10:53:45 -0500 From: Robert Dailey rcdailey.li...@gmail.com Subject: Re: [CMake] Secret precompiled header support? To: Dave Abrahams d...@boostpro.com Is the current implementation really satisfactory? For me, no. I'm trying to make a transition to CMake in a community where this is being seen as a problematic limitation. I actually was reading over the boost modularization discussion, but I didn't spend enough time there to understand what this whole process is for. I'm assuming this is being setup so users can download pieces of boost individually and only use the parts they want. I'm glad that Boost is making a real effort to use CMake. I think such an influential community being involved with CMake will help push Kitware to realize how serious people are taking their products and maybe they'll make a move to professionalize them. By that I mean, CMake is a great tool but very inconsistent and somewhat messy and obscure in a lot of areas. Major work needs to be done here to polish everything and make it feel organized and professional. You can claim portability all day but you have to do it right. Right now I feel CMake is 60% there. I say that because that 40% I had to implement via CMake scripts over the course of several months, resulting in a couple thousand lines of CMake code (to handle transitive include dependencies, compiler-agnostic features such as PCH and warning levels, private/public include directories, and other things). While a 60% estimation may sound a bit harsh, I have to admit that my own rating wouldn't be too far off either, given that only the *current* stable version can be stated to be relatively up to speed with shockingly mundane build (and more painfully, packaging) requirements. Especially the haphazard way of variable-style configuration needs to be reduced, in favour of more flexible property-style / helper function APIs configuration spaces (the CMAKE_MFC_FLAG variable or the - now improved - include_directories() thingy would be particularly striking examples here). OTOH implementing such a universal and flexible build system certainly is no small feat, and every single soul out there should ask her/himself which kind of all the critical fringe upstream work (fixing exotic Find modules, etc.) they THEMSELVES failed to do recently. Myself I certainly know of some parts where I have some upstream work remaining to be done... Not to mention that I'm sure that Kitware would love to be paid fairly for certain peripheral (perhaps less so) areas to be implemented. I also have a large number of rather clever (NOT! all this mostly shouldn't be necessary given an ideal - whatever that means - build environment) scripting parts to get everything packaged up the way God meant it to be. One major part that I'm missing is some *builtin* dos2unix/unix2dos flags of the file(COPY ...) commands (and perhaps configure_file()), BTW. Currently all this is emulated manually in a very painful way, whereas many major SCM tools have quite flexible d2u handling builtin... /rant (had to put this tag here for my admittedly less specific reply) BTW, I currently have an updated version of the community-maintained (see related tracker item) PCH support Module within my vcproj2cmake repo (since there are very obvious usage synergies), and I plan to keep it current. Of course I'm fully aware that you'd like to see improved CMake-builtin support instead... Andreas Mohr -- 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] Secret precompiled header support?
2012/5/15 Robert Dailey rcdailey.li...@gmail.com: On Tue, May 15, 2012 at 7:34 AM, Dave Abrahams d...@boostpro.com wrote: For me, no. I'm trying to make a transition to CMake in a community where this is being seen as a problematic limitation. I actually was reading over the boost modularization discussion, but I didn't spend enough time there to understand what this whole process is for. I'm assuming this is being setup so users can download pieces of boost individually and only use the parts they want. I'm glad that Boost is making a real effort to use CMake. I think such an influential community being involved with CMake will help push Kitware to realize how serious people are taking their products and maybe they'll make a move to professionalize them. I could not resist a troll like that. No offense but saying that CMake has to address such and such limitation/weirdiness seems ok to me, but going down to infer that no serious people do currently use CMake is a little hard to read... ...and... I'm not speaking for myself since I'm not considering myself as a serious guy anyway :-] All that said I can witness that serious patches are more than usually welcome :-) -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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] Secret precompiled header support?
On Tue, May 15, 2012 at 2:14 PM, Eric Noulard eric.noul...@gmail.comwrote: 2012/5/15 Robert Dailey rcdailey.li...@gmail.com: On Tue, May 15, 2012 at 7:34 AM, Dave Abrahams d...@boostpro.com wrote: For me, no. I'm trying to make a transition to CMake in a community where this is being seen as a problematic limitation. I actually was reading over the boost modularization discussion, but I didn't spend enough time there to understand what this whole process is for. I'm assuming this is being setup so users can download pieces of boost individually and only use the parts they want. I'm glad that Boost is making a real effort to use CMake. I think such an influential community being involved with CMake will help push Kitware to realize how serious people are taking their products and maybe they'll make a move to professionalize them. I could not resist a troll like that. No offense but saying that CMake has to address such and such limitation/weirdiness seems ok to me, but going down to infer that no serious people do currently use CMake is a little hard to read... ...and... I'm not speaking for myself since I'm not considering myself as a serious guy anyway :-] All that said I can witness that serious patches are more than usually welcome :-) -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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 I can't resist either: how much would you pay for a Professional Edition of CMake? :-) -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Secret precompiled header support?
No one has anything to say about this?
On Wed, May 9, 2012 at 1:32 PM, Robert Dailey rcdailey.li...@gmail.comwrote:
To my knowledge there are no dedicated target properties or commands that
allow one to easily add precompiled headers support to a target. In my
case, I'm generating for visual studio and I have the following that I can
use to enable precompiled headers:
macro( _precompiled_headers PrecompiledHeader PrecompiledSource SourcesVar
)
if( MSVC )
get_filename_component( PrecompiledBasename ${PrecompiledHeader} NAME_WE )
set( PrecompiledBinary
${CMAKE_CURRENT_BINARY_DIR}/${PrecompiledBasename}.pch )
set( Sources ${${SourcesVar}} )
set_property(
SOURCE ${PrecompiledSource} APPEND_STRING PROPERTY
COMPILE_FLAGS /Yc\${PrecompiledHeader}\ /Fp\${PrecompiledBinary}\
)
set_property(
SOURCE ${PrecompiledSource} APPEND PROPERTY
OBJECT_OUTPUTS ${PrecompiledBinary}
)
set_property(
SOURCE ${Sources} APPEND_STRING PROPERTY
COMPILE_FLAGS /Yu\${PrecompiledHeader}\ /Fp\${PrecompiledBinary}\
)
set_property(
SOURCE ${Sources} APPEND PROPERTY
OBJECT_DEPENDS ${PrecompiledBinary}
)
else()
message( Precompiled header support not provided for this platform )
endif()
# Add precompiled header to SourcesVar
list( APPEND ${SourcesVar} ${PrecompiledSource} )
endmacro()
The one interesting thing I have noticed is the way these compile flags
translate to actual vcproj output:
FileConfiguration
Name=MinSizeRel|Win32
Tool
Name=VCCLCompilerTool
ForcedIncludeFiles=C:/Code/work/cmake-decomp/cmake/files/source/hash_map_hack.hpp;StdAfx.cpp
PrecompiledHeaderFile=C:/Code/work/cmake-decomp/build-vc9/server/exchange/tools/uploadlog/StdAfx.pch
PrecompiledHeaderThrough=StdAfx.h
UsePrecompiledHeader=2
AdditionalDependencies=C:\Code\work\cmake-decomp\build-vc9\server\exchange\tools\uploadlog\StdAfx.pch
/
CMake seems to do more than just add them as general compiler flags, it
seems to know exactly which attributes in the VCPROJ XML are mapped to
their respective command line alternatives, and uses the appropriate ones.
If this is true, why do we not have a dedicated target source file
property that I can use to enable precompiled headers instead of using
these command line strings directly? Am I misunderstanding something?
--
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] Secret precompiled header support?
On 5/14/2012 2:26 PM, Robert Dailey wrote: No one has anything to say about this? CMake seems to do more than just add them as general compiler flags, it seems to know exactly which attributes in the VCPROJ XML are mapped to their respective command line alternatives, and uses the appropriate ones. If this is true, why do we not have a dedicated target source file property that I can use to enable precompiled headers instead of using these command line strings directly? Am I misunderstanding something? Nothing magic going on. With VS 2010 and greater, there is a python script that creates a flag mapping table from MS xml: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmparseMSBuildXML.py;h=4877e5913436dcf117580db286566b4f9568fc20;hb=HEAD cmparseMSBuildXML.py So, nothing specific was done for pre-compiled headers. To have them work cross platform is very difficult because of the wide variety in API by the compilers out there. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Secret precompiled header support?
On Mon, May 14, 2012 at 3:45 PM, Bill Hoffman bill.hoff...@kitware.comwrote: On 5/14/2012 2:26 PM, Robert Dailey wrote: No one has anything to say about this? CMake seems to do more than just add them as general compiler flags, it seems to know exactly which attributes in the VCPROJ XML are mapped to their respective command line alternatives, and uses the appropriate ones. If this is true, why do we not have a dedicated target source file property that I can use to enable precompiled headers instead of using these command line strings directly? Am I misunderstanding something? Nothing magic going on. With VS 2010 and greater, there is a python script that creates a flag mapping table from MS xml: http://cmake.org/gitweb?p=**cmake.git;a=blob;f=Source/** cmparseMSBuildXML.py;h=**4877e5913436dcf117580db286566b** 4f9568fc20;hb=HEADhttp://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmparseMSBuildXML.py;h=4877e5913436dcf117580db286566b4f9568fc20;hb=HEAD cmparseMSBuildXML.py So, nothing specific was done for pre-compiled headers. To have them work cross platform is very difficult because of the wide variety in API by the compilers out there. I'm seeing this behavior in VS 2003 and VS 2008 as well. Is the same script used by CMake for these generators too? It's working somehow... -- 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] Secret precompiled header support?
On 5/14/2012 5:48 PM, Robert Dailey wrote: I'm seeing this behavior in VS 2003 and VS 2008 as well. Is the same script used by CMake for these generators too? It's working somehow... For those we hard coded many of the flags into a table. So, basically for VS greater than 6, we have a table that maps flags to actual options in the IDE. There is no special per-compiled support in CMake... :) All it knows is that flat /Foobar == Turn on option foobar and creates the right xml or project input file. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Secret precompiled header support?
On Mon, May 14, 2012 at 4:58 PM, Bill Hoffman bill.hoff...@kitware.comwrote:
For those we hard coded many of the flags into a table. So, basically for
VS greater than 6, we have a table that maps flags to actual options in the
IDE. There is no special per-compiled support in CMake... :)
All it knows is that flat /Foobar == Turn on option foobar and creates
the right xml or project input file.
Thanks for the explanation.
It would be nice to have target properties for these, instead of this
obscure mapping. It makes it difficult to figure out how exactly to append
compiler flags. For example, I'm using set_property() with APPEND_STRING,
and I have to make sure my spacing is correct each time I enable a
compiler-specific feature using compiler flags. I had to use trial error
to determine that APPEND_STRINGS worked, but APPEND didn't for
COMPILE_FLAGS. There's a lot of boilerplate logic that I have to deal with
when using set_property with COMPILE_FLAGS.
It would be much easier to specify some target properties instead. Or maybe
to simplify things, we can have a compiler_flags() command that simplifies
doing this work, if it is undesirable to have new target properties?
Is improvement desired in this area? Is the current implementation really
satisfactory? It doesn't exactly offer an intuitive or maintainable
solution.
Here is what I have to do right now to enable precompiled headers on MSVC:
macro( _precompiled_headers PrecompiledHeader PrecompiledSource SourcesVar )
if( MSVC )
get_filename_component( PrecompiledBasename ${PrecompiledHeader} NAME_WE )
set( PrecompiledBinary
${CMAKE_CURRENT_BINARY_DIR}/${PrecompiledBasename}.pch )
set( Sources ${${SourcesVar}} )
set_property(
SOURCE ${PrecompiledSource} APPEND_STRING PROPERTY
COMPILE_FLAGS /Yc\${PrecompiledHeader}\ /Fp\${PrecompiledBinary}\
)
set_property(
SOURCE ${PrecompiledSource} APPEND PROPERTY
OBJECT_OUTPUTS ${PrecompiledBinary}
)
set_property(
SOURCE ${Sources} APPEND_STRING PROPERTY
COMPILE_FLAGS /Yu\${PrecompiledHeader}\ /Fp\${PrecompiledBinary}\
)
set_property(
SOURCE ${Sources} APPEND PROPERTY
OBJECT_DEPENDS ${PrecompiledBinary}
)
else()
message( Precompiled header support not provided for this platform )
endif()
# Add precompiled header to SourcesVar
list( APPEND ${SourcesVar} ${PrecompiledSource} )
endmacro()
I feel like CMake should offer me a higher-level way of dealing with this.
--
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] Secret precompiled header support?
Sorry, I forgot that I already had that code pasted in my original post.
Sorry for the duplicate code :)
On Mon, May 14, 2012 at 5:17 PM, Robert Dailey rcdailey.li...@gmail.comwrote:
On Mon, May 14, 2012 at 4:58 PM, Bill Hoffman bill.hoff...@kitware.comwrote:
For those we hard coded many of the flags into a table. So, basically
for VS greater than 6, we have a table that maps flags to actual options in
the IDE. There is no special per-compiled support in CMake... :)
All it knows is that flat /Foobar == Turn on option foobar and creates
the right xml or project input file.
Thanks for the explanation.
It would be nice to have target properties for these, instead of this
obscure mapping. It makes it difficult to figure out how exactly to append
compiler flags. For example, I'm using set_property() with APPEND_STRING,
and I have to make sure my spacing is correct each time I enable a
compiler-specific feature using compiler flags. I had to use trial error
to determine that APPEND_STRINGS worked, but APPEND didn't for
COMPILE_FLAGS. There's a lot of boilerplate logic that I have to deal with
when using set_property with COMPILE_FLAGS.
It would be much easier to specify some target properties instead. Or
maybe to simplify things, we can have a compiler_flags() command that
simplifies doing this work, if it is undesirable to have new target
properties?
Is improvement desired in this area? Is the current implementation really
satisfactory? It doesn't exactly offer an intuitive or maintainable
solution.
Here is what I have to do right now to enable precompiled headers on MSVC:
macro( _precompiled_headers PrecompiledHeader PrecompiledSource SourcesVar
)
if( MSVC )
get_filename_component( PrecompiledBasename ${PrecompiledHeader} NAME_WE )
set( PrecompiledBinary
${CMAKE_CURRENT_BINARY_DIR}/${PrecompiledBasename}.pch )
set( Sources ${${SourcesVar}} )
set_property(
SOURCE ${PrecompiledSource} APPEND_STRING PROPERTY
COMPILE_FLAGS /Yc\${PrecompiledHeader}\ /Fp\${PrecompiledBinary}\
)
set_property(
SOURCE ${PrecompiledSource} APPEND PROPERTY
OBJECT_OUTPUTS ${PrecompiledBinary}
)
set_property(
SOURCE ${Sources} APPEND_STRING PROPERTY
COMPILE_FLAGS /Yu\${PrecompiledHeader}\ /Fp\${PrecompiledBinary}\
)
set_property(
SOURCE ${Sources} APPEND PROPERTY
OBJECT_DEPENDS ${PrecompiledBinary}
)
else()
message( Precompiled header support not provided for this platform )
endif()
# Add precompiled header to SourcesVar
list( APPEND ${SourcesVar} ${PrecompiledSource} )
endmacro()
I feel like CMake should offer me a higher-level way of dealing with this.
--
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] Secret precompiled header support?
To my knowledge there are no dedicated target properties or commands that
allow one to easily add precompiled headers support to a target. In my
case, I'm generating for visual studio and I have the following that I can
use to enable precompiled headers:
macro( _precompiled_headers PrecompiledHeader PrecompiledSource SourcesVar )
if( MSVC )
get_filename_component( PrecompiledBasename ${PrecompiledHeader} NAME_WE )
set( PrecompiledBinary
${CMAKE_CURRENT_BINARY_DIR}/${PrecompiledBasename}.pch )
set( Sources ${${SourcesVar}} )
set_property(
SOURCE ${PrecompiledSource} APPEND_STRING PROPERTY
COMPILE_FLAGS /Yc\${PrecompiledHeader}\ /Fp\${PrecompiledBinary}\
)
set_property(
SOURCE ${PrecompiledSource} APPEND PROPERTY
OBJECT_OUTPUTS ${PrecompiledBinary}
)
set_property(
SOURCE ${Sources} APPEND_STRING PROPERTY
COMPILE_FLAGS /Yu\${PrecompiledHeader}\ /Fp\${PrecompiledBinary}\
)
set_property(
SOURCE ${Sources} APPEND PROPERTY
OBJECT_DEPENDS ${PrecompiledBinary}
)
else()
message( Precompiled header support not provided for this platform )
endif()
# Add precompiled header to SourcesVar
list( APPEND ${SourcesVar} ${PrecompiledSource} )
endmacro()
The one interesting thing I have noticed is the way these compile flags
translate to actual vcproj output:
FileConfiguration
Name=MinSizeRel|Win32
Tool
Name=VCCLCompilerTool
ForcedIncludeFiles=C:/Code/work/cmake-decomp/cmake/files/source/hash_map_hack.hpp;StdAfx.cpp
PrecompiledHeaderFile=C:/Code/work/cmake-decomp/build-vc9/server/exchange/tools/uploadlog/StdAfx.pch
PrecompiledHeaderThrough=StdAfx.h
UsePrecompiledHeader=2
AdditionalDependencies=C:\Code\work\cmake-decomp\build-vc9\server\exchange\tools\uploadlog\StdAfx.pch
/
CMake seems to do more than just add them as general compiler flags, it
seems to know exactly which attributes in the VCPROJ XML are mapped to
their respective command line alternatives, and uses the appropriate ones.
If this is true, why do we not have a dedicated target source file
property that I can use to enable precompiled headers instead of using
these command line strings directly? Am I misunderstanding something?
--
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
