thr3ads.net - llvm dev - [LLVMdev] RFC: I plan to remove the autoconf and Makefile build of LLD [Mar 2015]

If this information is useful, please help other people find it:
Share via:

Iain Sandoe

2015-Mar-16 11:59 UTC

[LLVMdev] RFC: I plan to remove the autoconf and Makefile build of LLD

Hi Chris,

On 14 Mar 2015, at 21:42, Chris Bieneman wrote:
> Just out of curiosity. The community generally seems to be moving away from
autoconf toward CMake. Is there a reason why you need the autoconf build bad
enough to support it out-of-tree?
The reasons a short-term and boring engineering/project-related, rather than
ideological.

We all agree that one well-maintained build system is desirable; FAOD I have no
axe to grind over which it is - providing it supports the hosts, targets and
use-cases we care about.
> Today supporting LLD’s autoconf build out-of-tree probably isn’t that bad
because LLD is fairly small and LLVM still has a functioning autoconf build
system. However, if LLVM moves off autoconf (and you’re stuck on it for some
reason) you may be in the awful position of needing to support LLVM’s autoconf
build out-of-tree, which would be pretty terrible.
I suspect that the typical  development-builder of the compiler is interested in
a self-host on one host platform, possibly with limitation to one (or maybe two)
revisions of the host system (there are exceptions, of course) ..

That is considerably different from our use-case; we support a wide range of
toolchains across several platforms (and often quite wide ranges of versions). 
We are building integrated toolchains with a bunch of components from several
sources (including internal and client-provided).  It is expected by some of our
clients that these will be supportable for possibly years to come.

It's completely impracticable to support that kind of arrangement with an
array of different host boxen with a second array of configurations; ergo our
usual use-case is cross (or, in some cases, "canadian") builds.

Perhaps not surprisingly, we have a significant system to handle build, test, QA
and release of these toolchains.  At present, there is no other call for cmake
in that system and none of the LLVM projects in my group have any resources
assigned to switching to the build/test/etc. to use cmake.

Thus, in the short-term (since, as you say, things are currently simple) local
maintenance of the lld makefiles is the most economical approach.

We continually review the situation internally and all the folks you see
contributing regularly to llvm, clang and lldb have WIP cmake implementations. 
I hope that we can get that stuff in place before the plug is finally pulled on
autoconf.
> If there is a deficiency in the CMake build system that keeps you from
using it, we should track that as a blocker for removing autoconf from LLVM and
address it.
My observation is that, if one strays from the "beaten path" (which I
equate to self-host on one platform) - with either cmake or auto-fu, then things
tend not to work completely (or as you might expect)  :-) ...
.. thus I expect we'll need to do some maintenance either way - but
that's life!

Apologies if I sounded grumpy,
Iain
> 
> Thanks,
> -Chris
> 
>> On Mar 13, 2015, at 12:23 PM, Iain Sandoe <iain at
codesourcery.com> wrote:
>> 
>> I fixed the immediate problem - please let me know when you are going
to break my build so I can switch to maintaining it locally.
>> thanks
>> Iain
>> ]
>> On 13 Mar 2015, at 17:04, Rui Ueyama wrote:
>> 
>>> Looks like most developers prefer Makefile removal, and there's
no push-back. Let's go ahead and remove them. I'll send a patch.
>>> 
>>> On Wed, Mar 11, 2015 at 3:33 PM, Iain Sandoe <iain at
codesourcery.com> wrote:
>>> I have fixed the issue locally, but been out of the office - can
apply the fix - or just maintain the makefiles locally if no-one else really
wants them,
>>> 
>>> fine with whatever the community decision is.
>>> Iain
>>> 
>>> On 11 Mar 2015, at 22:11, Rui Ueyama wrote:
>>> 
>>>> I'd agree, but the Makefiles were added just 9 months ago.
I don't know if there's a real need of any kind. Added Iain who added
these files.
>>>> 
>>>> On Wed, Mar 11, 2015 at 3:10 PM, Chandler Carruth <chandlerc
at gmail.com> wrote:
>>>> This time with the correct mailing list address... See below...
>>>> 
>>>> On Wed, Mar 11, 2015 at 3:07 PM, Chandler Carruth <chandlerc
at gmail.com> wrote:
>>>> Why?
>>>> 
>>>> 1) We're moving away from autoconf already today. We're
hoping to drop it completely soon.
>>>> 2) It doesn't work today and no one is complaining.
>>>> 3) It hasn't worked for weeks and no one has complained.
>>>> 
>>>> Due to #2 and #3, I believe it is dead code. I can't even
test my changes to it because it doesn't work.
>>>> 
>>>> I don't want to invest time fixing it if we're moving
the other direction.
>>>> 
>>>> -Chandler
>>>> 
>>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150316/7e9f1d1d/attachment.html>

Chris Bieneman

2015-Mar-16 18:57 UTC

head link

[LLVMdev] RFC: I plan to remove the autoconf and Makefile build of LLD

> On Mar 16, 2015, at 4:59 AM, Iain Sandoe <iain at codesourcery.com>
wrote:
> 
> Hi Chris,
> 
> On 14 Mar 2015, at 21:42, Chris Bieneman wrote:
> 
>> Just out of curiosity. The community generally seems to be moving away
from autoconf toward CMake. Is there a reason why you need the autoconf build
bad enough to support it out-of-tree?
> 
> The reasons a short-term and boring engineering/project-related, rather
than ideological.
Gotcha.
> 
> We all agree that one well-maintained build system is desirable; FAOD I
have no axe to grind over which it is - providing it supports the hosts, targets
and use-cases we care about.
> 
>> Today supporting LLD’s autoconf build out-of-tree probably isn’t that
bad because LLD is fairly small and LLVM still has a functioning autoconf build
system. However, if LLVM moves off autoconf (and you’re stuck on it for some
reason) you may be in the awful position of needing to support LLVM’s autoconf
build out-of-tree, which would be pretty terrible.
> 
> I suspect that the typical  development-builder of the compiler is
interested in a self-host on one host platform, possibly with limitation to one
(or maybe two) revisions of the host system (there are exceptions, of course) ..
> 
> That is considerably different from our use-case; we support a wide range
of toolchains across several platforms (and often quite wide ranges of
versions).  We are building integrated toolchains with a bunch of components
from several sources (including internal and client-provided).  It is expected
by some of our clients that these will be supportable for possibly years to
come.
> 
> It's completely impracticable to support that kind of arrangement with
an array of different host boxen with a second array of configurations; ergo our
usual use-case is cross (or, in some cases, "canadian") builds.
My team primarily cross compiles LLVM from OS X to arm, so that isn’t too far
fetched of a use case. I’ve actually upstreamed almost all our CMake goop to
make it work, and am actively supporting cross-compilation in the CMake build
system. There are some issues still with compiler-rt, but I’m hopeful we can get
those worked out eventually too.
> 
> Perhaps not surprisingly, we have a significant system to handle build,
test, QA and release of these toolchains.  At present, there is no other call
for cmake in that system and none of the LLVM projects in my group have any
resources assigned to switching to the build/test/etc. to use cmake.
> 
> Thus, in the short-term (since, as you say, things are currently simple)
local maintenance of the lld makefiles is the most economical approach.
> 
> We continually review the situation internally and all the folks you see
contributing regularly to llvm, clang and lldb have WIP cmake implementations. 
I hope that we can get that stuff in place before the plug is finally pulled on
autoconf.
I don’t think this is imminent, but I really would love to have autoconf given
the boot this year.
> 
>> If there is a deficiency in the CMake build system that keeps you from
using it, we should track that as a blocker for removing autoconf from LLVM and
address it.
> 
> My observation is that, if one strays from the "beaten path"
(which I equate to self-host on one platform) - with either cmake or auto-fu,
then things tend not to work completely (or as you might expect)  :-) ...
> .. thus I expect we'll need to do some maintenance either way - but
that's life!
If you have specific issues I’d be more than happy to help. I’m very interested
in making CMake better for cross compilation.
> 
> Apologies if I sounded grumpy,
Anyone who messes with build systems is entitled to a healthy bit of grump — I
know I take more than my fair share :-).

-Chris
> Iain
> 
>> 
>> Thanks,
>> -Chris
>> 
>>> On Mar 13, 2015, at 12:23 PM, Iain Sandoe <iain at
codesourcery.com <mailto:iain at codesourcery.com>> wrote:
>>> 
>>> I fixed the immediate problem - please let me know when you are
going to break my build so I can switch to maintaining it locally.
>>> thanks
>>> Iain
>>> ]
>>> On 13 Mar 2015, at 17:04, Rui Ueyama wrote:
>>> 
>>>> Looks like most developers prefer Makefile removal, and
there's no push-back. Let's go ahead and remove them. I'll send a
patch.
>>>> 
>>>> On Wed, Mar 11, 2015 at 3:33 PM, Iain Sandoe <iain at
codesourcery.com <mailto:iain at codesourcery.com>> wrote:
>>>> I have fixed the issue locally, but been out of the office -
can apply the fix - or just maintain the makefiles locally if no-one else really
wants them,
>>>> 
>>>> fine with whatever the community decision is.
>>>> Iain
>>>> 
>>>> On 11 Mar 2015, at 22:11, Rui Ueyama wrote:
>>>> 
>>>>> I'd agree, but the Makefiles were added just 9 months
ago. I don't know if there's a real need of any kind. Added Iain who
added these files.
>>>>> 
>>>>> On Wed, Mar 11, 2015 at 3:10 PM, Chandler Carruth
<chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote:
>>>>> This time with the correct mailing list address... See
below...
>>>>> 
>>>>> On Wed, Mar 11, 2015 at 3:07 PM, Chandler Carruth
<chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote:
>>>>> Why?
>>>>> 
>>>>> 1) We're moving away from autoconf already today.
We're hoping to drop it completely soon.
>>>>> 2) It doesn't work today and no one is complaining.
>>>>> 3) It hasn't worked for weeks and no one has
complained.
>>>>> 
>>>>> Due to #2 and #3, I believe it is dead code. I can't
even test my changes to it because it doesn't work.
>>>>> 
>>>>> I don't want to invest time fixing it if we're
moving the other direction.
>>>>> 
>>>>> -Chandler
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>       
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150316/74538567/attachment.html>

Rui Ueyama

2015-Mar-26 20:13 UTC

head link

[LLVMdev] RFC: I plan to remove the autoconf and Makefile build of LLD

I've submitted r233313 to remove Makefiles from the repository.

On Mon, Mar 16, 2015 at 11:57 AM, Chris Bieneman <beanz at apple.com>
wrote:
>
> On Mar 16, 2015, at 4:59 AM, Iain Sandoe <iain at codesourcery.com>
wrote:
>
> Hi Chris,
>
> On 14 Mar 2015, at 21:42, Chris Bieneman wrote:
>
> Just out of curiosity. The community generally seems to be moving away
> from autoconf toward CMake. Is there a reason why you need the autoconf
> build bad enough to support it out-of-tree?
>
>
> The reasons a short-term and boring engineering/project-related, rather
> than ideological.
>
>
> Gotcha.
>
>
> We all agree that one well-maintained build system is desirable; FAOD I
> have no axe to grind over which it is - providing it supports the hosts,
> targets and use-cases we care about.
>
> Today supporting LLD’s autoconf build out-of-tree probably isn’t that bad
> because LLD is fairly small and LLVM still has a functioning autoconf build
> system. However, if LLVM moves off autoconf (and you’re stuck on it for
> some reason) you may be in the awful position of needing to support LLVM’s
> autoconf build out-of-tree, which would be pretty terrible.
>
>
> I suspect that the typical  development-builder of the compiler is
> interested in a self-host on one host platform, possibly with limitation to
> one (or maybe two) revisions of the host system (there are exceptions, of
> course) ..
>
> That is considerably different from our use-case; we support a wide range
> of toolchains across several platforms (and often quite wide ranges of
> versions).  We are building integrated toolchains with a bunch of
> components from several sources (including internal and client-provided).
> It is expected by some of our clients that these will be supportable for
> possibly years to come.
>
> It's completely impracticable to support that kind of arrangement with
an
> array of different host boxen with a second array of configurations; ergo
> our usual use-case is cross (or, in some cases, "canadian")
builds.
>
>
> My team primarily cross compiles LLVM from OS X to arm, so that isn’t too
> far fetched of a use case. I’ve actually upstreamed almost all our CMake
> goop to make it work, and am actively supporting cross-compilation in the
> CMake build system. There are some issues still with compiler-rt, but I’m
> hopeful we can get those worked out eventually too.
>
>
> Perhaps not surprisingly, we have a significant system to handle build,
> test, QA and release of these toolchains.  At present, there is no other
> call for cmake in that system and none of the LLVM projects in my group
> have any resources assigned to switching to the build/test/etc. to use
> cmake.
>
> Thus, in the short-term (since, as you say, things are currently simple)
> local maintenance of the lld makefiles is the most economical approach.
>
> We continually review the situation internally and all the folks you see
> contributing regularly to llvm, clang and lldb have WIP cmake
> implementations.  I hope that we can get that stuff in place before the
> plug is finally pulled on autoconf.
>
>
> I don’t think this is imminent, but I really would love to have autoconf
> given the boot this year.
>
>
> If there is a deficiency in the CMake build system that keeps you from
> using it, we should track that as a blocker for removing autoconf from LLVM
> and address it.
>
>
> My observation is that, if one strays from the "beaten path"
(which I
> equate to self-host on one platform) - with either cmake or auto-fu, then
> things tend not to work completely (or as you might expect)  :-) ...
> .. thus I expect we'll need to do some maintenance either way - but
that's
> life!
>
>
> If you have specific issues I’d be more than happy to help. I’m very
> interested in making CMake better for cross compilation.
>
>
> Apologies if I sounded grumpy,
>
>
> Anyone who messes with build systems is entitled to a healthy bit of grump
> — I know I take more than my fair share :-).
>
> -Chris
>
> Iain
>
>
> Thanks,
> -Chris
>
> On Mar 13, 2015, at 12:23 PM, Iain Sandoe <iain at codesourcery.com>
wrote:
>
> I fixed the immediate problem - please let me know when you are going to
> break my build so I can switch to maintaining it locally.
> thanks
> Iain
> ]
> On 13 Mar 2015, at 17:04, Rui Ueyama wrote:
>
> Looks like most developers prefer Makefile removal, and there's no
> push-back. Let's go ahead and remove them. I'll send a patch.
>
> On Wed, Mar 11, 2015 at 3:33 PM, Iain Sandoe <iain at
codesourcery.com>
> wrote:
>
>> I have fixed the issue locally, but been out of the office - can apply
>> the fix - or just maintain the makefiles locally if no-one else really
>> wants them,
>>
>> fine with whatever the community decision is.
>> Iain
>>
>> On 11 Mar 2015, at 22:11, Rui Ueyama wrote:
>>
>> I'd agree, but the Makefiles were added just 9 months ago. I
don't know
>> if there's a real need of any kind. Added Iain who added these
files.
>>
>> On Wed, Mar 11, 2015 at 3:10 PM, Chandler Carruth <chandlerc at
gmail.com>
>> wrote:
>>
>>> This time with the correct mailing list address... See below...
>>>
>>> On Wed, Mar 11, 2015 at 3:07 PM, Chandler Carruth <chandlerc at
gmail.com>
>>> wrote:
>>>
>>>> Why?
>>>>
>>>> 1) We're moving away from autoconf already today. We're
hoping to drop
>>>> it completely soon.
>>>> 2) It doesn't work today and no one is complaining.
>>>> 3) It hasn't worked for weeks and no one has complained.
>>>>
>>>> Due to #2 and #3, I believe it is dead code. I can't even
test my
>>>> changes to it because it doesn't work.
>>>>
>>>> I don't want to invest time fixing it if we're moving
the other
>>>> direction.
>>>>
>>>> -Chandler
>>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150326/d25d7883/attachment.html>

llvm dev - Mar 2015 - [LLVMdev] RFC: I plan to remove the autoconf and Makefile build of LLD

[LLVMdev] RFC: I plan to remove the autoconf and Makefile build of LLD

[LLVMdev] RFC: I plan to remove the autoconf and Makefile build of LLD

[LLVMdev] RFC: I plan to remove the autoconf and Makefile build of LLD