<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 1/12/16 12:47 PM, Chris Bieneman via
llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:AC57BC4B-3506-480F-B6F1-6036F4674E6C@apple.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jan 12, 2016, at 9:39 AM, Reid Kleckner <<a
moz-do-not-send="true" href="mailto:rnk@google.com"
class=""><a class="moz-txt-link-abbreviated" href="mailto:rnk@google.com">rnk@google.com</a></a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Sounds like a plan.
<div class=""><br class="">
</div>
<div class="">Should we leave behind a simple ./configure
script that checks for cmake, and if present, runs
something like 'cmake -G"Unix Makefiles" .'? I think
it's nice if the "standard" Unix way of building with
"./configure && make" keeps working.</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>My intention had been to leave the configure script having
it print an error directing people to CMake. I hesitate to
make the configure script to anything other than error out
because people like to pass arguments to configure.</div>
</div>
</blockquote>
<br>
+1, IMHO. Autoconf-based configure scripts are expected to have
certain behaviors (e.g., Autoconf allows one to write a configure
script that checks for and runs another autoconf script in a
subdirectory with the same --prefix option and other options). I
would hesitate to have a non-Autoconf-compliant configure script.<br>
<br>
Regards,<br>
<br>
John Criswell<br>
<br>
<blockquote
cite="mid:AC57BC4B-3506-480F-B6F1-6036F4674E6C@apple.com"
type="cite">
<div>
<div><br class="">
</div>
<div>Maybe if configure is called with no arguments we do a
default build, but if arguments are specified we fail out?</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class=""><br class="">
</div>
<div class="">Also, we should be able to allow in-source
cmake builds once we remove the makefiles, right?</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Maybe. In source builds will need all conflicting makefiles
to be removed, so enabling it before all projects have their
makefiles removed might be a bit complicated.</div>
<div><br class="">
</div>
<div>-Chris</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Tue, Jan 12, 2016 at 9:35 AM,
Chris Bieneman via llvm-dev <span dir="ltr" class=""><<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" class=""><a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a></a>></span>
wrote:<br class="">
<blockquote class="gmail_quote">Now that 3.8 is
imminently branching with the newly deprecated
autoconf I think it is time to propose a process and
timeline for removing autoconf support from trunk.<br
class="">
<br class="">
At this point I believe there should be no users of
autoconf for Clang and LLVM that are not supported by
CMake, so I would like to propose dropping autoconf
support from the cfe and llvm repositories on January
26th (two weeks from today). I believe this gives
sufficient time for users to migrate any remaining
systems off autoconf. If this timeline doesn’t work
for you, please speak up.<br class="">
<br class="">
There are still some problematic use cases for
building the compiler-rt builtins. Specifically
bootstrapping cross-compilers is fragile and in some
cases entirely unworkable in CMake. To this end I’m
not proposing a full removal of the compiler-rt
makefiles at this time. What I would like to propose
is that on February 2nd we remove autoconf support for
all sanitizer runtimes from compiler-rt.<br class="">
<br class="">
We will not be removing the makefile build system from
the test-suite project. The CMake build system there
is very new, and still nowhere near feature complete.<br
class="">
<br class="">
For other projects (libcxx, libcxxabi, libunwind…)
I’ve not made significant contributions to these
projects, so I’d like to defer to more active
contributors on those projects, but I am unaware of
any blocking issues.<br class="">
<br class="">
Questions, comments, concerns, panic, fire, brimstone?<br
class="">
<br class="">
-Chris<br class="">
_______________________________________________<br
class="">
LLVM Developers mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br
class="">
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br
class="">
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
<a class="moz-txt-link-freetext" href="http://www.cs.rochester.edu/u/criswell">http://www.cs.rochester.edu/u/criswell</a></pre>
</body>
</html>