<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Matt Rogers wrote:
<blockquote cite="mid200608091954.05065.mattr@kde.org" type="cite">
<pre wrap="">On Wednesday 09 August 2006 19:26, Brandon J. Van Every wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Matt Rogers wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
Would the CMake developers be interested in patches that allows people to
use their already installed libraries such as curl, expat, libtar, etc.
on certain platforms and fallback to the in-source libraries if they're
not installed?
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
You misunderstand. *sigh* Apparently, I suck at explaining myself today.. :(
</pre>
<blockquote type="cite">
<pre wrap="">Anyone can already write this kind of code using FindXXX and FIND_*
commands and then some conditionals. It is not difficult CMake script
code to write. You seem to be saying it should / could be automagical.
I'm not convinced that's beneficial, however. When people include the
entire source of a library in their own build tree, it's because they
want control over how the thing is built. For instance, the source code
may have diverged from standard distributions, may be older, may be
frozen, may be built with CMake instead of Autoconf and be integrated
with CTest, etc. When people don't want that level of control, they
implement FindXXX and FIND_* commands. I doubt you can provide patches
that make FindXXX and FIND_* any better than they currently are, so this
part of the problem never goes away. It's code that people have to write.
</pre>
</blockquote>
<pre wrap=""><!---->
No, I'm not saying that it should be automagical. I'm saying that when
building CMake, I want to be allowed to use my own versions of curl, expat,
libtar, etc. instead of the ones that are shipped as part of the CMake source
code. This means that I would write the necessary Find*.cmake files and use
the necessary commands in the build to do this. However, before I waste any
time on another endeavour that will be rejected by the CMake developers, I
wanted to ask if this would be something worthwhile to them.
</pre>
</blockquote>
<br>
Ah. Well, it's a good test of the principle, that buildmasters build
their own sources their own way for a reason.<br>
<br>
<br>
<blockquote cite="mid200608091954.05065.mattr@kde.org" type="cite">
<pre wrap="">
I don't know how bootstrapping CMake works on windows,</pre>
</blockquote>
<br>
I use CMake to build VS .NET 2003 project files, which I then use to
build CMake. VS .NET 2003 or similar is necessary because of the
dependency on MFC. You can't freely obtain a working MFC. There's
some sample weirdo AMD64 crap in the PSDK that some people have hacked
to make a sort of half-assed MFC, but it is totally unsupported,
doesn't work, is somewhat sick and wrong given the way Microsoft builds
things, etc.<br>
<br>
<br>
<blockquote cite="mid200608091954.05065.mattr@kde.org" type="cite">
<pre wrap=""> which is which i
initially proposed that it be unix/linux only. If we can make it work on
windows, great, if not, well, then, it'll work for at least one, if not two,
of the three supported platforms.
</pre>
</blockquote>
<br>
I'll hazard a guess that offering to create special cases for a build
is not going to be received warmly in the absence of demonstrable
value, but I could be mistaken. Anyways, why is using your own libcurl
etc. important?<br>
<br>
<br>
Cheers,<br>
Brandon Van Every<br>
<br>
</body>
</html>