Of course, I'm making generalities here but without reading each and every. Its detection of dependencies is also heavily flawed, partially since it prefers hard-coded paths to those returned by pkg-config which is a tool versatile enough to cover basically all build needs. I find cmake more difficult to work with especially when it comes to cross-compilation. Otherwise, it has been my experience that most people who contribute patches test them only on the platforms they care about, so it ends up taking me more time to test and integrate and fix and extend those patches than it would have taken for me to develop them myself. I will not entertain any pull requests for this unless the submitter has demonstrated that all of the above steps have been done or unless the submitter is willing to fund my labor to do testing and integration of the patches. This is easily 30 hours of work on my part, so not something I can do for free- at least not in the near term. Extensive testing on all of the platforms we support.Modifying the testing framework so that traditional "make test" targets are still available on Un*x and Mac.Porting Un*x/Mac-specific stuff from autotools to CMake- including the entire packaging system.Porting all of the SIMD/assembler detection stuff from acinclude.m4 into CMake.Whether it lands will depend largely on whether I can secure funding, either directly or indirectly through the General Fund for one of my other projects, to implement this the "right way." If there are no strong objections, I would like this to land in libjpeg-turbo 1.6, so speak now or forever hold your peace. I think that most of the cross-compilation issues can be addressed by simply modifying the recipes in BUILDING.md to document the steps necessary to cross-compile libjpeg-turbo under CMake. I need feedback from the community- particularly those who are maintaining libjpeg-turbo packages for Linux distros, etc.- as to whether this will create any significant downstream problems. Referring to my comments in the above issues, there are very good reasons why I absolutely will not entertain the notion of supporting multiple build systems on the same platform, so supporting CMake on non-Windows platforms will mean dropping support for autotools altogether. However, there are some things that autotools does better, such as cross-compilation. I generally prefer CMake to autotools, and it would be convenient to have only one build system. I've been getting those requests off and on since the project was founded. Numerous requests, including most recently #21, #29, and #37, have been received for implementing CMake build system support for non-Windows platforms.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |