3 Commits

Author	SHA1	Message	Date
Chandler Carruth	bff1e8d53d	Enhance the GCC version parsing and comparison logic to handle some more ... edge cases and have better behavior. Specifically, we should actually prefer the general '4.6' version string over the '4.6.1' string, as '4.6.2' should be able to replace it without breaking rpaths or any other place that these paths have been embedded. Debian-based distributions are already using a path structure with symlinks to achieve in-place upgrades for patch versions. Now our parsing reflects this and we select the shorter paths instead of the longer paths. A separate issue was that we would not parse a leading patch version number even in the presence of a suffix. The above change makes this more problematic as it would cause a suffix being added to make us treat the entire thing as patch-version-agnostic, which it isn't. This changes the logic to distinguish between '4.4.x' and 4.4.1-x', and retain that the latter has *some* patch number information. Currently, we always bias toward the shorter and more canonical version strings. If it becomes important we can add more Debian like rules to produce sequences such as '4.4.1b' > '4.4.1' > '4.4.1-rc3' > '4.4.1-rc2' > '4.4.1-pre5', but I'm very doubtful this will ever matter or be desirable. I've made the tests for this logic a bit more interesting, and added some specific tests for logic that is now different. llvm-svn: 143841	2011-11-05 23:24:30 +00:00
Chandler Carruth	e276b3662b	Use the InstalledDir correctly, and test it correctly as well. =/ Should ... have noticed this previously, sorry. llvm-svn: 141167	2011-10-05 06:38:03 +00:00
Chandler Carruth	cf59bc5939	Teach Clang to cope with GCC installations that have unusual patch ... "versions". Currently, these are just dropped on the floor, A concrete version number will always win out. llvm-svn: 141159	2011-10-05 03:09:51 +00:00