Bug in cmake (or more likely the makefile?), pure and simple. Version numbers aren't strings, and they aren't floating point numbers, they are a series of integers separated by dots. I can't think of a project where interpreting version numbers that way won't work.
On Wed, Jun 15, 2016 at 7:21 AM, Cristianno Martins via llvm-dev < llvm-...@lists.llvm.org> wrote: > Hello there, > > First, I would like to say that I don't have any strong opinions on this > matter: as mostly an user of LLVM, my basic concern is for me to be able to > identify which version is the newest and configure it as easily as > possible. That being said, I have a question about LLVM's versioning > strategy: is it possible for other tools (including the ones LLVM depend > on) to become broke or annoyingly buggy just because a bad versioning > scheme was put in place? > > Just to give some context to this question, I've been using OS X for a > while, and I confess I was pretty annoyed when OS X 10.9 was followed by OS > X 10.10. Not at first, no: I didn't realize this would have any impact on > my workspace until I had to compile some code, and CMake kept stopping just > because it recognized that I was using an older version of the OS (emphasis > on *older*). It is funny when you realize that 10.10 should actually be > interpreted as less than 10.9, and CMake was falling for it, which was a > wrong behavior of the tool, I admit, but the weird OS versioning scheme was > the main cause of this issue. Of course this problem can be easily arranged > by setting up some extra environment variables to tell CMake to target OS X > 10.9 instead, but that was a very irritating behavior and only happened > because a bunch of people (from CMake, and, then, from OS X's development > team) thought comparing versions directly shouldn't be a problem. Besides, > every one of these small details end up being some extra steps a new user > need to follow to be able to use a tool, some of which could be easily > avoided. > > I confess I didn't look into this matter after that, and still today, on > OS X 10.11, I'm targeting version 10.9 on all my CMake runs on OS X -- > thus, I don't know if this bug was fixed or not. However, as I'm starting > to see a very similar pattern happening with LLVM on this thread, and I > thought I could contribute with the discussion: did someone check if naming > the next version "3.10" would have any impact on a production system? > > > -- > Cristianno Martins > <cristiannomart...@hotmail.com> > > On Tue, Jun 14, 2016 at 10:48 PM, Sean Silva via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> >> >> On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev < >> cfe-...@lists.llvm.org> wrote: >> >>> >>> >>> On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev < >>> cfe-...@lists.llvm.org> wrote: >>> >>>> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev < >>>> lldb-dev@lists.llvm.org> wrote: >>>> >>>>> ----- Original Message ----- >>>>> > From: "Hans Wennborg via cfe-dev" <cfe-...@lists.llvm.org> >>>>> > To: "llvm-dev" <llvm-...@lists.llvm.org>, "cfe-dev" < >>>>> cfe-...@lists.llvm.org>, "LLDB Dev" <lldb-dev@lists.llvm.org>, >>>>> > "openmp-dev (openmp-...@lists.llvm.org)" <openmp-...@lists.llvm.org> >>>>> > Cc: "r jordans" <r.jord...@tue.nl>, "Paul Robinson" < >>>>> paul_robin...@playstation.sony.com> >>>>> > Sent: Monday, June 13, 2016 6:54:19 PM >>>>> > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] >>>>> Release plan and call for testers) >>>>> > >>>>> > Breaking this out into a separate thread since it's kind of a >>>>> > separate >>>>> > issue, and to make sure people see it. >>>>> > >>>>> > If you have opinions on this, please chime in. I'd like to collect as >>>>> > many arguments here as possible to make a good decision. The main >>>>> > contestants are 4.0 and 3.10, and I've seen folks being equally >>>>> > surprised by both. >>>>> > >>>>> > Brain-dump so far: >>>>> > >>>>> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0 >>>>> > comes after 3.9. >>>>> > >>>>> > - There are special bitcode stability rules [1] concerning major >>>>> > version bumps. 2.0 and 3.0 had major IR changes, but since there >>>>> > aren't any this time, we should go to 3.10. >>>>> > >>>>> > - The bitcode stability rules allow for breakage with major versions, >>>>> > but it doesn't require it, so 4.0 is fine. >>>>> > >>>>> > - But maybe we want to save 4.0 for when we do have a significant IR >>>>> > change? >>>>> >>>>> I think that this is the right approach, and we happen to have a >>>>> natural forcing function here: opaque pointer types. I think we should >>>>> increment the major version number when opaque pointer types are here, as >>>>> it will be a major breaking change, and then we'll have a version 4.0. >>>>> Until then, unless something else breaking comes up, 3.10 sounds fine to >>>>> me. >>>>> >>>> >>>> +1, complete agreement. >>>> >>> >>> While I'm not sure opaque pointer types are going to increment versions >>> I'm also in agreement that 3.10 is the right way to go. >>> >> >> +1 >> >> -- Sean Silva >> >> >>> >>> -eric >>> >>> >>>> _______________________________________________ >>>> cfe-dev mailing list >>>> cfe-...@lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>>> >>> >>> _______________________________________________ >>> cfe-dev mailing list >>> cfe-...@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>> >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > > _______________________________________________ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
