On 9/27/07, Hendrik Sattler <[EMAIL PROTECTED]> wrote: > Am Freitag 28 September 2007 schrieb Brandon Van Every: > > I can't see why any CMake-oriented person would > > recommend pkg-config unless they're stuck with it as a legacy concern. > > And with a cmake centric solution, you create yet another dead-end unless you > propose cmake as the ultimate and only valid solution.
CMake *is* the ultimate and only valid solution. We're certainly not going to work on better Autoconf support, and pkg-config is an Autoconf-based build. If the pkg-config developers want to move away from Autoconf and dependence on Unix shells for operation, that would be great. But the willingness has to come from them. I've been there, done that with Unix developers who were open to CMake conversions, but really didn't have any bona fide cross-platform commitment to Windows. The endgame is they throw out your work the minute they actually have to lift a finger to support MSVC, because that's easier for them and they don't care. You can't convert people to The CMake Way [TM] unless they actually have a reason to go there. And The CMake Way does not include support and integration of Autoconf, except insofar as people want to roll their own ADD_CUSTOM_COMMANDs. > If pkgconfig does not > currently cope well with plain win32, why did nobody bother to fix it instead > of damning it? Feel free, if you've got the time. Don't presume to volunteer other people's time though. It's a scarce resource, and most of us put it into things that we think are going to last. If you think pkg-config is really more important than CMake, I'd say your need for CMake isn't that strong. You know, I've been there, done that also. Had a bunch of Unix developers decide that packaging tools that all required Autoconf were more important than learning how to use CMake and supporting MSVC. They cared about their Unix packages, not about cross-platform GCC and MSVC support. I hope that someday cpack is robust, well documented, and works with various package formats so that this kind of political problem goes away. > At least it is a build-system-independent solution. You're wrong. It's dependent on Autoconf and Unix shells for its existence. It could be *made* build system independent, but that's what would have to be fixed. And you'd have to get the willingness of the pkg-config developers to fix it. Otherwise politically you're DOA. Cheers, Brandon Van Every _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
