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

This time with the correct mailing list address… See below…

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.

I'm really in favour of axing them. Thanks for taking care of it.

I’m fine keeping this until we can undertake the larger effort, but:

  1. No build bot seems to be testing it.
  2. No active developers (on any part of LLVM) seem to be testing it.

So I fear that it isn’t sustainable in its current state.

+1, thanks!

-Greg

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

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.

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
]

Sure. I sent a patch for review already, waiting for LGTM.

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?

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.

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.

Thanks,
-Chris

Hi Chris,

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) :slight_smile:
… thus I expect we’ll need to do some maintenance either way - but that’s life!

Apologies if I sounded grumpy,
Iain

Hi Chris,

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) :slight_smile:
… 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

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