Re: [CMake] FindModules.cmake quality + Kitware proposition
I'll add to it that all the Find Modules should be able to support projects that have their own builds of a library. Some Find Modules (e.g FindBoost) works generally well and supports HINTS and PATHS; but other (FindCURL) do not. For me, this means that I'll have to be adding variations of numerous modules to get it done so everything links and works correctly when I'd rather just use what CMake already provides. $0.02 Ben On Thursday, May 14, 2015 11:16 AM, Nagy-Egri Máté Ferenc via CMake wrote: This is more of a remark, or something to get the ball rolling, rather than anything else. I recently came across various FindModule.cmake files (FindOpenCL, FindOpenGL, FindGLEW, FindGLM, FindSFML) as a sideeffect of a project I am developing, but have had my share with quite a few others (FindQt, RustCMake, FindOpenAL, FindBoost, …). My overall impression is that the quality of these modules is highly fluctuating to say the least. While generally the FindModules shipping with CMake as built-in scripts are usable, there is a fair amount of room for improvement. FindGLEW.cmake for eg. is terrible. I have never imagined that such a widely used library has a 7 line FindModule script. On Windows it is practically useless. As for nearly all other FindModule scripts, nearly none of them use target_include_libraries() that would allow for end-users of the scripts to not have to worry about include directories. Some projects strive at being cross-platform, but compiling them on Windows (mostly the GNU projects that aim on being Windows friendly) is massive pain. libJPEG to name just one provides nmake makefiles that are capable of producing Visual Studio 2010 project files at best (huuraay), and have undocumented external dependencies. These projects (and their users) cry out for CMake support. Here is a proposition to consider: Kitware generally has the philosphy with CMake being: do it yourself or hire us to do it. While on a corporate basis this is a legitimate approach, I as a poor academic fellow do not have 10.000$ to spare for a feature I so wish, neither do I have the time to educate myself in the internal ways of CMake to contribute. So all I do is hack, hack, hack all day. The Chocolatey project (a package manager for Windows) recently won a massive Kickstarter campaign that aimed solely increasing the overall quality of the project. With this campaign they aimed on growing from an ‘interesting idea’ to begin ‘mainstream’. With the money they won, they hired full time package moderators, developed automated scripts of facilitating authoring, wrote tutorials, created templates, and even managed to get the ball rolling with OneGet (Powershell 5.0 package manager manager) to adopt Chocolatey as the first supported public repo. I would suggest Kitware start a similar community funded project to increase the overall quality of the software. While I do not have 10 grands to buy a feature, I do have 10 dollars pocket money to contribute (as do MANY others). As several levels of goals, the stock FindModules scripts could be brought to a homogenous quality, identical naming conventions (no more MYLIB_INC_DIR, MYLIB_INCLUDE_DIRS, MyLib_INCLUDE_DIR), high quality templates for new adopters, make the CMake Guide freely available online (epub, pdf, docx, whatever), convert 10 GNU projects to CMake, convert 50 GNU projects to CMake, create Snappy back-end of CPack, or my personal favorite (the feature I do not have 10.000 dollars for) is NMake batch mode support for multicore build, etc. There are so many places CMake itself can be improved, and so many users who really should be adopting, but have not started due to lacking man power. (These are the projects that would benefit the most from a freely available tutorial, because truth be told: writing capable, high-quality CMake scripts is no easy task.) If I were a charmismatic spokesperson I’d say: I RAISE 10 DOLLARS, WHO’S WITH ME?! But because I’m not, I’ll just leave it here as a suggestion. Ideas? -- 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 -- 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.ht
Re: [CMake] FindModules.cmake quality + Kitware proposition
Auto-generating things seems like a good idea, as most CMake scripting feels like boilerplate. The majority of the projects do the same things, so it only makes sense to try getting some automation working. Perhaps it might go all the way to obtaining sources if not found on the computer, similar to what Cargo does with Rust. As for the bountysource.com page, it is a good initiative. Perhaps a link to it on the CMake website would be useful. Cheers, Máté Feladó: cmake@cmake.org Elküldve: csütörtök, 2015. május 14. 21:24 Címzett: cmake@cmake.org On 14-May-15 14:01, Nagy-Egri Máté Ferenc via CMake wrote: This is more of a remark, or something to get the ball rolling, rather than anything else. I recently came across various FindModule.cmake files (FindOpenCL, FindOpenGL, FindGLEW, FindGLM, FindSFML) as a sideeffect of a project I am developing, but have had my share with quite a few others (FindQt, RustCMake, FindOpenAL, FindBoost, …). My overall impression is that the quality of these modules is highly fluctuating to say the least. While generally the FindModules shipping with CMake as built-in scripts are usable, there is a fair amount of room for improvement. FindGLEW.cmake for eg. is terrible. I have never imagined that such a widely used library has a 7 line FindModule script. On Windows it is practically useless. As for nearly all other FindModule scripts, nearly none of them use target_include_libraries() that would allow for end-users of the scripts to not have to worry about include directories. Some projects strive at being cross-platform, but compiling them on Windows (mostly the GNU projects that aim on being Windows friendly) is massive pain. libJPEG to name just one provides nmake makefiles that are capable of producing Visual Studio 2010 project files at best (huuraay), and have undocumented external dependencies. These projects (and their users) cry out for CMake support. Here is a proposition to consider: This sounds like a workaround for the existing problems. What we really need to do to solve this issue completely is to use automatically generated Find-like modules - Config.cmake. See: http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages Kitware generally has the philosphy with CMake being: do it yourself or hire us to do it. While on a corporate basis this is a legitimate approach, I as a poor academic fellow do not have 10.000$ to spare for a feature I so wish, neither do I have the time to educate myself in the internal ways of CMake to contribute. So all I do is hack, hack, hack all day. The Chocolatey project (a package manager for Windows) recently won a massive Kickstarter campaign that aimed solely increasing the overall quality of the project. With this campaign they aimed on growing from an ‘interesting idea’ to begin ‘mainstream’. With the money they won, they hired full time package moderators, developed automated scripts of facilitating authoring, wrote tutorials, created templates, and even managed to get the ball rolling with OneGet (Powershell 5.0 package manager manager) to adopt Chocolatey as the first supported public repo. I would suggest Kitware start a similar community funded project to increase the overall quality of the software. While I do not have 10 grands to buy a feature, I do have 10 dollars pocket money to contribute (as do MANY others). As several levels of goals, the stock FindModules scripts could be brought to a homogenous quality, identical naming conventions (no more MYLIB_INC_DIR, MYLIB_INCLUDE_DIRS, MyLib_INCLUDE_DIR), high quality templates for new adopters, make the CMake Guide freely available online (epub, pdf, docx, whatever), convert 10 GNU projects to CMake, convert 50 GNU projects to CMake, create Snappy back-end of CPack, or my personal favorite (the feature I do not have 10.000 dollars for) is NMake batch mode support for multicore build, etc. There are so many places CMake itself can be improved, and so many users who really should be adopting, but have not started due to lacking man power. (These are the projects that would benefit the most from a freely available tutorial, because truth be told: writing capable, high-quality CMake scripts is no easy task.) If I were a charmismatic spokesperson I’d say: I RAISE 10 DOLLARS, WHO’S WITH ME?! But because I’m not, I’ll just leave it here as a suggestion. Ideas? Have you seen https://www.bountysource.com/ ? Ruslo-- 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
Re: [CMake] FindModules.cmake quality + Kitware proposition
On 14-May-15 14:01, Nagy-Egri Máté Ferenc via CMake wrote: This is more of a remark, or something to get the ball rolling, rather than anything else. I recently came across various FindModule.cmake files (FindOpenCL, FindOpenGL, FindGLEW, FindGLM, FindSFML) as a sideeffect of a project I am developing, but have had my share with quite a few others (FindQt, RustCMake, FindOpenAL, FindBoost, …). My overall impression is that the quality of these modules is highly fluctuating to say the least. While generally the FindModules shipping with CMake as built-in scripts are usable, there is a fair amount of room for improvement. FindGLEW.cmake for eg. is terrible. I have never imagined that such a widely used library has a 7 line FindModule script. On Windows it is practically useless. As for nearly all other FindModule scripts, nearly none of them use target_include_libraries() that would allow for end-users of the scripts to not have to worry about include directories. Some projects strive at being cross-platform, but compiling them on Windows (mostly the GNU projects that aim on being Windows friendly) is massive pain. libJPEG to name just one provides nmake makefiles that are capable of producing Visual Studio 2010 project files at best (huuraay), and have undocumented external dependencies. These projects (and their users) cry out for CMake support. Here is a proposition to consider: This sounds like a workaround for the existing problems. What we really need to do to solve this issue completely is to use automatically generated Find-like modules - Config.cmake. See: http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages Kitware generally has the philosphy with CMake being: do it yourself or hire us to do it. While on a corporate basis this is a legitimate approach, I as a poor academic fellow do not have 10.000$ to spare for a feature I so wish, neither do I have the time to educate myself in the internal ways of CMake to contribute. So all I do is hack, hack, hack all day. The Chocolatey project (a package manager for Windows) recently won a massive Kickstarter campaign that aimed solely increasing the overall quality of the project. With this campaign they aimed on growing from an ‘interesting idea’ to begin ‘mainstream’. With the money they won, they hired full time package moderators, developed automated scripts of facilitating authoring, wrote tutorials, created templates, and even managed to get the ball rolling with OneGet (Powershell 5.0 package manager manager) to adopt Chocolatey as the first supported public repo. I would suggest Kitware start a similar community funded project to increase the overall quality of the software. While I do not have 10 grands to buy a feature, I do have 10 dollars pocket money to contribute (as do MANY others). As several levels of goals, the stock FindModules scripts could be brought to a homogenous quality, identical naming conventions (no more MYLIB_INC_DIR, MYLIB_INCLUDE_DIRS, MyLib_INCLUDE_DIR), high quality templates for new adopters, make the CMake Guide freely available online (epub, pdf, docx, whatever), convert 10 GNU projects to CMake, convert 50 GNU projects to CMake, create Snappy back-end of CPack, or my personal favorite (the feature I do not have 10.000 dollars for) is NMake batch mode support for multicore build, etc. There are so many places CMake itself can be improved, and so many users who really should be adopting, but have not started due to lacking man power. (These are the projects that would benefit the most from a freely available tutorial, because truth be told: writing capable, high-quality CMake scripts is no easy task.) If I were a charmismatic spokesperson I’d say: I RAISE 10 DOLLARS, WHO’S WITH ME?! But because I’m not, I’ll just leave it here as a suggestion. Ideas? Have you seen https://www.bountysource.com/ ? Ruslo -- 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] FindModules.cmake quality + Kitware proposition
Nagy-Egri MC!tC\) Ferenc via CMake wrote: > Tried jom years ago. Still chokes on Unicode paths. Ok, I guess the jom developers are the ones to discuss that issue with. Thanks, Steve. -- 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] FindModules.cmake quality + Kitware proposition
Tried jom years ago. Still chokes on Unicode paths. Thanks, Máté ps.: I had a feeling this is as much feedback as I’ll get. Feladó: Stephen Kelly Elküldve: csütörtök, 2015. május 14. 18:08 Címzett: cmake@cmake.org Nagy-Egri Máté Ferenc via CMake wrote: > ... NMake batch mode support for multicore build, etc. I suggest you look into 'jom'. Thanks, Steve. -- 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-- 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] FindModules.cmake quality + Kitware proposition
Nagy-Egri Máté Ferenc via CMake wrote: > ... NMake batch mode support for multicore build, etc. I suggest you look into 'jom'. Thanks, Steve. -- 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] FindModules.cmake quality + Kitware proposition
This is more of a remark, or something to get the ball rolling, rather than anything else. I recently came across various FindModule.cmake files (FindOpenCL, FindOpenGL, FindGLEW, FindGLM, FindSFML) as a sideeffect of a project I am developing, but have had my share with quite a few others (FindQt, RustCMake, FindOpenAL, FindBoost, …). My overall impression is that the quality of these modules is highly fluctuating to say the least. While generally the FindModules shipping with CMake as built-in scripts are usable, there is a fair amount of room for improvement. FindGLEW.cmake for eg. is terrible. I have never imagined that such a widely used library has a 7 line FindModule script. On Windows it is practically useless. As for nearly all other FindModule scripts, nearly none of them use target_include_libraries() that would allow for end-users of the scripts to not have to worry about include directories. Some projects strive at being cross-platform, but compiling them on Windows (mostly the GNU projects that aim on being Windows friendly) is massive pain. libJPEG to name just one provides nmake makefiles that are capable of producing Visual Studio 2010 project files at best (huuraay), and have undocumented external dependencies. These projects (and their users) cry out for CMake support. Here is a proposition to consider: Kitware generally has the philosphy with CMake being: do it yourself or hire us to do it. While on a corporate basis this is a legitimate approach, I as a poor academic fellow do not have 10.000$ to spare for a feature I so wish, neither do I have the time to educate myself in the internal ways of CMake to contribute. So all I do is hack, hack, hack all day. The Chocolatey project (a package manager for Windows) recently won a massive Kickstarter campaign that aimed solely increasing the overall quality of the project. With this campaign they aimed on growing from an ‘interesting idea’ to begin ‘mainstream’. With the money they won, they hired full time package moderators, developed automated scripts of facilitating authoring, wrote tutorials, created templates, and even managed to get the ball rolling with OneGet (Powershell 5.0 package manager manager) to adopt Chocolatey as the first supported public repo. I would suggest Kitware start a similar community funded project to increase the overall quality of the software. While I do not have 10 grands to buy a feature, I do have 10 dollars pocket money to contribute (as do MANY others). As several levels of goals, the stock FindModules scripts could be brought to a homogenous quality, identical naming conventions (no more MYLIB_INC_DIR, MYLIB_INCLUDE_DIRS, MyLib_INCLUDE_DIR), high quality templates for new adopters, make the CMake Guide freely available online (epub, pdf, docx, whatever), convert 10 GNU projects to CMake, convert 50 GNU projects to CMake, create Snappy back-end of CPack, or my personal favorite (the feature I do not have 10.000 dollars for) is NMake batch mode support for multicore build, etc. There are so many places CMake itself can be improved, and so many users who really should be adopting, but have not started due to lacking man power. (These are the projects that would benefit the most from a freely available tutorial, because truth be told: writing capable, high-quality CMake scripts is no easy task.) If I were a charmismatic spokesperson I’d say: I RAISE 10 DOLLARS, WHO’S WITH ME?! But because I’m not, I’ll just leave it here as a suggestion. Ideas?-- 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
