Announcement

Collapse
No announcement yet.

Libjpeg-Turbo 2.0 Beta Brings More AVX2 SIMD, Improved CMake Build System

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

  • Libjpeg-Turbo 2.0 Beta Brings More AVX2 SIMD, Improved CMake Build System

    Phoronix: Libjpeg-Turbo 2.0 Beta Brings More AVX2 SIMD, Improved CMake Build System

    A Phoronix reader recently pointed out that LibJPEG 2.0 Beta quietly shipped last month as working towards the next big update for this speed-focused JPEG library...

    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
    It seems that many projects are dropping AutoTools in favour of CMake, Meson or something else. Is the Open Source software world going to lose anything when AutoTools is no longer in wide use? Does AutoTools have any advantages over CMake and Meson?

    Comment


    • #3
      Originally posted by cybertraveler View Post
      It seems that many projects are dropping AutoTools in favour of CMake, Meson or something else. Is the Open Source software world going to lose anything when AutoTools is no longer in wide use? Does AutoTools have any advantages over CMake and Meson?
      I personally like the traditional configure scrips, but other than that, the alternatives are better in every way, and many projects write manual configure scripts to replace the autoconf ones.

      Comment


      • #4
        Originally posted by cybertraveler View Post
        It seems that many projects are dropping AutoTools in favour of CMake, Meson or something else. Is the Open Source software world going to lose anything when AutoTools is no longer in wide use? Does AutoTools have any advantages over CMake and Meson?
        Autotools is an old sophisticated piece of shit, to put it mildly. Google "gnu autohell"
        Last edited by cl333r; 22 April 2018, 02:00 PM.

        Comment


        • #5
          Originally posted by carewolf View Post

          I personally like the traditional configure scrips
          Do you think that might be because you have become used to its syntax and behaviour over time and thus you have developed a kind-of, comfortable familiarity with it? Do you think you'd have the same preference for configure scripts if you had started out using configure scripts, CMake lists and Meson build files equally?

          I'm just curious about this. I'm genuinely wondering if AutoTools has some benefit over CMake and Meson which will ensure it has a role in the future.

          Comment


          • #6
            Originally posted by cybertraveler View Post
            It seems that many projects are dropping AutoTools in favour of CMake, Meson or something else. Is the Open Source software world going to lose anything when AutoTools is no longer in wide use? Does AutoTools have any advantages over CMake and Meson?
            it varies. Autotools is certainly not without issues *for the developer*. For the user (end user or distro) it's great, very standardized, useful-ish --help etc.
            But there's so much existing out there that even the developer can mostly cut and paste.

            CMake is great for the developer, but it sucks for the user, especially a distro. None of the "really should be standard" flags are standardized, so each project does weird variations of these. (simple example, how do you tell it to use /usr/lib64 for libraries)

            Meson seems to be getting to a point where it's both great for the developer and the user. It's not nearly as flexible as CMake, but to be honest, that's a good thing. It makes simple logical things simple for the developer, but these things then are nicely standardized for the end user. E.g. it's a lot more prescriptive than either cmake or even autotools, but in a way that helps rather than hurts devs and users

            Comment


            • #7
              Originally posted by arjan_intel View Post

              CMake is great for the developer, but it sucks for the user, especially a distro. None of the "really should be standard" flags are standardized, so each project does weird variations of these. (simple example, how do you tell it to use /usr/lib64 for libraries)
              With export LDFLAGS='-L/usr/lib64' ?

              That worked for quite a few software builds, and those that did not required PKG_CONFIG_PATH anyway.

              Comment


              • #8
                Originally posted by cybertraveler View Post
                It seems that many projects are dropping AutoTools in favour of CMake, Meson or something else. Is the Open Source software world going to lose anything when AutoTools is no longer in wide use? Does AutoTools have any advantages over CMake and Meson?
                Well, developers also dropped support for FORTRAN, ALGOL, SIMULA, PASCAL and so on. A rolling stone gathers no moss.

                Comment


                • #9
                  Originally posted by cybertraveler View Post
                  It seems that many projects are dropping AutoTools in favour of CMake, Meson or something else. Is the Open Source software world going to lose anything when AutoTools is no longer in wide use? Does AutoTools have any advantages over CMake and Meson?
                  Autotools has one *huge* advantage over the others: it *just* works.

                  Comment


                  • #10
                    It seems better for the compiler to handle this stuff, rather than trying to add it in the library/application code. I get why they want to do it (they have to distribute generic x86 code for compatibility/portability).

                    ​​​​​​It seems better to distribute most libraries/apps as intermediate representations (e.g LLVM IR) and your computer can then compile to machine code at installation time. That way, the compiled code runs at full soees using native instructions, but doesn't need to compile from scratch.

                    This approach is already followed by many languages, e.g Java where your VM converts intermediate representation (Java bytecode) to machine code at runtime (JIT compilation). Android takes this a step further, and does what I described in the previous paragraph, since Android 5.0.

                    Comment

                    Working...
                    X