Announcement

Collapse
No announcement yet.

GNU Automake 1.15.1 Comes After A Stall In The Project

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GNU Automake 1.15.1 Comes After A Stall In The Project

    Phoronix: GNU Automake 1.15.1 Comes After A Stall In The Project

    GNU's Automake 1.15.1 release is now available, which isn't too big on new work but comes after a lack of activity on Automake...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I'll read the release details later, with a clear head. But I am the only one disturbed by the apparent problems with "lack of activity, date of last release"? Code doesn't rot. Code is like mathematical expressions. Elegant solutions don't, shouldn't, get old, and need new code. Meta-software like automake should reach eventual stability, and then require very few and far between updates, and eventually none.

    Correct me if I'm wrong, but I metaphor Automake as a waiter in a restaurant. The menu might change, the cook might modify how he does what he does, and your payment method might vary, but how you place your order should eventually become very standard and predictable, and not change.

    I apologize if I am philosophical. Where I am, it is a hot humid hellish night. A few beers have helped cool my spirit, but not my head.

    Comment


    • #3
      Originally posted by AndyChow View Post
      I'll read the release details later, with a clear head. But I am the only one disturbed by the apparent problems with "lack of activity, date of last release"? Code doesn't rot. Code is like mathematical expressions. Elegant solutions don't, shouldn't, get old, and need new code. Meta-software like automake should reach eventual stability, and then require very few and far between updates, and eventually none..

      Actually in this case there was some rot. Specifically a deprecation of something over a 5 year period in perl. Basically allowing unescaped { in regex had been known to cause issues with parsing certain regex and prevented the addition of other features. Patches had been available in automake/autoconf's source control for multiple years (4 i think) but were never released because it wasn't seen by them as a pressing issue. With the release of perl 5.26, the deprecation period is over and it's now a fatal error to have the unescaped left brace in a regex. This release of perl also came with some security fixes and many distros are planning on packaging it in their next release (or sooner) because of that. So you've got a newer Perl that can't be used with the old automake/autoconf because despite them having a fix for years for the problem and knowing about this day coming, they've not released it. This is a textbook definition of code rot, fixes that have existed and were known to be necessary were never released until after they became so.

      Comment


      • #4
        Originally posted by simcop2387 View Post


        Actually in this case there was some rot. Specifically a deprecation of something over a 5 year period in perl. Basically allowing unescaped { in regex had been known to cause issues with parsing certain regex and prevented the addition of other features. Patches had been available in automake/autoconf's source control for multiple years (4 i think) but were never released because it wasn't seen by them as a pressing issue. With the release of perl 5.26, the deprecation period is over and it's now a fatal error to have the unescaped left brace in a regex. This release of perl also came with some security fixes and many distros are planning on packaging it in their next release (or sooner) because of that. So you've got a newer Perl that can't be used with the old automake/autoconf because despite them having a fix for years for the problem and knowing about this day coming, they've not released it. This is a textbook definition of code rot, fixes that have existed and were known to be necessary were never released until after they became so.
        Thank you for your insight, very much appreciated.

        Comment


        • #5
          Originally posted by AndyChow View Post
          Code doesn't rot. Code is like mathematical expressions. Elegant solutions don't, shouldn't, get old, and need new code.
          Code is not like math. A math expression is usually 100% independent from any other, code in modern complex programs (and most older complex ones too) is interconnected to other code that isn't standing still.

          Failure to keep your project up-to-date with the changes means it's bitrotting, eventually reaching a stage where it can't be used in a modern system anymore because all the other stuff is too different and it can't interact with it.

          Comment


          • #6
            The reason why it stalls is probably because every sane person on the planet now uses CMake..

            Comment


            • #7
              ..or because it is done(tm). I haven't ever come up with a missing feature in automake, so maybe all it needs are bugfixes like these perl deprecation updates.

              Comment


              • #8
                Originally posted by cen1 View Post
                The reason why it stalls is probably because every sane person on the planet now uses CMake..
                I see more and more projects (including a couple of popular ones) switching over to Meson rather than CMake...

                Comment


                • #9
                  Usually if I am in a need for c/c++ library and I am scouring the github projects my first check is whether the project contains CMakeLists.txt file. If hat is present I just know I can usually build it in 2 simple steps. I am yet to encounter a meson project. Not that this has any statistical significance.

                  On the other hand, seeing a Makefile sets off all kind of alarms in my head.

                  Comment


                  • #10
                    Originally posted by cen1 View Post
                    Usually if I am in a need for c/c++ library and I am scouring the github projects my first check is whether the project contains CMakeLists.txt file. If hat is present I just know I can usually build it in 2 simple steps. I am yet to encounter a meson project. Not that this has any statistical significance.

                    On the other hand, seeing a Makefile sets off all kind of alarms in my head.
                    CMake is a much older and more prolific project, no doubt about that. A lot of Linux projects (GNOME, systemd, parts of XOrg and graphics stack) have moved to Meson in recent months though.

                    I agree that seeing a plain Makefile is usually a bad sign and very few of them are well made by hand but Autotools is a different beast.

                    Comment

                    Working...
                    X