[llvm-dev] [RFC] Removing autoconf from trunk

John Criswell via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 12 10:02:41 PST 2016


On 1/12/16 12:47 PM, Chris Bieneman via llvm-dev wrote:
>
>> On Jan 12, 2016, at 9:39 AM, Reid Kleckner <rnk at google.com 
>> <mailto:rnk at google.com>> wrote:
>>
>> Sounds like a plan.
>>
>> 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.
>
> 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.

+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.

Regards,

John Criswell

>
> Maybe if configure is called with no arguments we do a default build, 
> but if arguments are specified we fail out?
>
>>
>> Also, we should be able to allow in-source cmake builds once we 
>> remove the makefiles, right?
>
> 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.
>
> -Chris
>
>>
>> On Tue, Jan 12, 2016 at 9:35 AM, Chris Bieneman via llvm-dev 
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>>     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.
>>
>>     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.
>>
>>     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.
>>
>>     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.
>>
>>     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.
>>
>>     Questions, comments, concerns, panic, fire, brimstone?
>>
>>     -Chris
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160112/8b27577b/attachment.html>


More information about the llvm-dev mailing list