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

> On Jan 12, 2016, at 9:39 AM, Reid Kleckner <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.

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
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160112/2eb82398/attachment.html>

Hm, given that we can't yet remove the compiler-rt makefiles, it's
probably
best to just make ./configure error with explicit instructions on how to
run cmake in a separate build directory.

On Tue, Jan 12, 2016 at 9:47 AM, Chris Bieneman <beanz at apple.com>
wrote:
>
> On Jan 12, 2016, at 9:39 AM, Reid Kleckner <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.
>
> 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> 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
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160112/396a5c13/attachment.html>

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>

> Also, we should be able to allow in-source cmake builds once we remove the
> makefiles, right?
I'm strongly against enabling in-source cmake builds. Apart from being
IMHO bad practise
certain parts of our CMake files may be assuming. the build is out of
source (e.g. I had a patch recently that assumed this because
in-source builds were impossible at the time).

We seemed to be doing fine so far without in-source cmake builds so I
see no good reason to add support for them.

Maybe the request stems from the (common) misunderstanding that the build folder
cannot be inside the source dir.

source_dir/build_dir where build_dir is a subfolder of source_dir and
doesn't contain any CMakeFiles.txt is *not* an in source build in CMake
terms.

An in source build is when source_dir == build_dir and I agree that this
shouldn't have to be supported and should be considered a bad practice with
CMake and IMO has absolutely no advantage.

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roemer at igd.fraunhofer.de  |  www.igd.fraunhofer.de


-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Dan Liew
via llvm-dev
Sent: Wednesday, January 13, 2016 23:52
To: Chris Bieneman
Cc: llvm-dev
Subject: Re: [llvm-dev] [RFC] Removing autoconf from trunk
> Also, we should be able to allow in-source cmake builds once we remove 
> the makefiles, right?
I'm strongly against enabling in-source cmake builds. Apart from being IMHO
bad practise certain parts of our CMake files may be assuming. the build is out
of source (e.g. I had a patch recently that assumed this because in-source
builds were impossible at the time).

We seemed to be doing fine so far without in-source cmake builds so I see no
good reason to add support for them.
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 1/13/16 3:52 PM, Dan Liew via llvm-dev wrote:
>> Also, we should be able to allow in-source cmake builds once we remove
the
>> makefiles, right?
>
> I'm strongly against enabling in-source cmake builds. Apart from being
> IMHO bad practise
> certain parts of our CMake files may be assuming. the build is out of
> source (e.g. I had a patch recently that assumed this because
> in-source builds were impossible at the time).
>
> We seemed to be doing fine so far without in-source cmake builds so I
> see no good reason to add support for them.
+1

It's so hard to achieve clean out-of-source builds when folks start 
doing in-source-builds... but this is important for maintaining build 
reproducibility. At the very least, if in-source builds are to be 
allowed, there ought to be a buildbot that complains when modifications 
to the source tree happen in out-of-source builds (and perhaps that 
ought to be something that we have anyway?).


Jon
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded