[CMake] Interresting dependency problem

[Brandon Van Every]

On 9/27/07, Hendrik Sattler <post at hendrik-sattler.de> 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