Comment 18 for bug 792146

(In reply to comment #2)
> Looking at current trunk, it looks like something was done about the hardcoded
> list of gcc versions:
> http://llvm.org/viewvc/llvm-project?view=rev&revision=143874
>
> However, nothing has been done about the hardcoded list of distros and distro
> release files. There is still
>
> enum LinuxDistro {
> ArchLinux,
> DebianLenny,
> DebianSqueeze,
> DebianWheezy,
> Exherbo,
> RHEL4,
> RHEL5,
> RHEL6,
> Fedora13,
> Fedora14,
> Fedora15,
> FedoraRawhide,
> OpenSuse11_3,
> OpenSuse11_4,
> OpenSuse12_1,
> UbuntuHardy,
> UbuntuIntrepid,
> UbuntuJaunty,
> UbuntuKarmic,
> UbuntuLucid,
> UbuntuMaverick,
> UbuntuNatty,
> UbuntuOneiric,
> UnknownDistro
> };
>
> along with code to parse /etc/lsb-release, /etc/redhat-release,
> /etc/debian_version, /etc/SuSE-release, /etc/exherbo-release, and
> /etc/arch-release to detect which of these distros is running.

Much of this code is dead. We don't use the Linux distro detection for much now other than a few fairly random bits, and I had thought all of those only cared about distinguishing between suse, ubuntu, debian, and everything-else.

I'm going to continue cleaning this up as time permits, but what would help me is if you listed specific actions with Clang which break because of this. Unless we have something specific that breaks because of this, I don't think keeping a PR open about the design cruft is all that useful...

> Maybe a stopgap solution would be to treat unknown Ubuntu releases as
> UbuntuOneiric, unknown Fedora releases as FedoraRawhide, etc. instead of
> categorizing all distros from the future as UnknownDistro. But I think the
> entire idea of looking at /etc/*-release files to guess the right linker flags
> is a violation of abstraction.

No one is really arguing that it is a good abstraction, but we need to know the concrete things it breaks. It does actually fix things. My personal goal is that for large, common Linux distributions no patch or configuration step is necessary to build a Clang which can compile and link binaries on that system. Doing this is not easy given the peculiarities of several distributions' packaging practices (I'm looking at you Debian/Ubuntu and your multiarch madness). That said, we should key behavior on the actual detected toolchain of the system, not on the /etc/...-release files.