<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
[redirected to CMake-Promote, because my thoughts are primarily about
marketing.]<br>
<br>
<br>
Thomas Zander wrote:
<blockquote cite="mid200605270810.20243.zander@kde.org" type="cite">
<pre wrap="">On Friday 26 May 2006 21:42, Brandon J. Van Every wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Another issue is that an autoconf ./configure script typically relies
on libtool. You don't wanna go there.
</pre>
</blockquote>
<pre wrap=""><!---->
Read my other mails in this thread please; its the NAME ONLY I suggested
to use.
If the configure script is just 4kb and does nothing but provide a
familiar front end to the cmake command (which I asserted earlier is not
user friendly enough) then I'm happy.
Nobody was suggesting to go back to auto*</pre>
</blockquote>
<br>
I think stealing some command line options from ./configure is a good
idea. i.e. "cmake --prefix=/foo". It would give people familiar with
./configure a warm squishy feeling.<br>
<br>
I don't know if distributing a shell script named "configure" that runs
cmake is a good idea. It's definitely a politically provocative move.
I'd be a bit worried about all the autoconf guys crying foul and there
being some kind of backlash. I'm not sure what kind of concrete damage
it could do, but possibly, unwillingness to promote CMake, and
uncooperativeness in getting it into distributions? Will, what do you
think?<br>
<br>
Perhaps a "boil the frog slowly" approach could work here:<br>
<br>
- first get CMake consistently in all the Linux distributions and etc.<br>
<br>
- second, implement the ./configure-style command line options in
CMake, to the extent that they're applicable. I think it's perfectly
reasonable to have both --prefix and --cmake_install_prefix do the same
thing. "cmake --help" would show both options. Refine the options
according to user feedback.<br>
<br>
- once that foundation is laid, THEN go for the jugular of bumping off
Autoconf ./configure scripts. I think we'd be on morally higher ground
if we're providing most of the options that the ./configure crowd wants.<br>
<br>
Of course, if cmake is not installed, the ./configure script would
complain and point out where to get it. Especially, if Linux
distributions are well in order, it could point out some methods for
getting cmake. I think some distros have command lines you can type to
get stuff. The ./configure script could fire those off. Command could
be something like "./configure --get_cmake". If someone runs
./configure and cmake isn't available, it could tell you to type
"./configure --get_cmake".<br>
<br>
<br>
Cheers,<br>
Brandon Van Every<br>
<br>
<br>
</body>
</html>