On Aug 28, 2015 9:24 AM, "Rainer Jung" <rainer.j...@kippdata.de> wrote: > > Am 28.08.2015 um 15:20 schrieb Michael Schlenker: >> >> Cmake provided project/nmake/make files have one issue though, which >> might not be obvious to someone never using cmake: Those depend on cmake >> for a variety of tasks (e.g. install tasks are often done by invoking >> some 'cmake -E' stuff and so on, via extra build tasks). > > I want to strengthen this point: IMHO very similar to configure, using cmake as a generator without having cmake on the system where you run the build likely will not work. You can't just run it at release time, generate nmake or vcxproj files and the consumer only uses MSVC to do the build. The end user will need to run cmake on his system. I have seen cmake calls in the generated nmake files, but also full absolute paths to extracted source files etc. in the generated vcxproj files. So those can't be generated at release time. > > I'm not terribly experienced with cmake though and maybe it has a more friendly generation mode. > > Despite those problems, I don't know of a better way to maintain the build artefacts we need to ensure windows platform support.
That's been my experience too so far with pcre. I am working on citrus bsd iconv as my first pcre scheme so I should learn a lot (this is needed to kill off apr-iconv windows support.) That said, dsp/dsw suffers the same issues. We have my fix scripts for that very reason. So I don't know that the issue will be as critical as we fear. Most of the configure time choices are to build a loadable component, and the core lib doesn't need to know which will be buildable. It didn't even support install, we have makefile.win for that, and I can't see it going away. If pcre provides a good alternative for install, great, but it is not critical. >> But to make it really good, there should be some standard FindAPR.cmake >> file provided (and sent to kitware for inclusion), to make it easier for >> packages using apr to detect the bits, pieces and parts. +1
