Announcement

Collapse
No announcement yet.

Meson: A Next-Gen Build System Showing Promise

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

  • #16
    SCons suxx. And this is python crap as well?

    Scons proven to be really unusable and bugged piece of shit when it comes to building programs. Its my least favorite of all build systems at all. And this one is some python crap too?

    And to be honest, when it comes to building software, my favorite would be autotools. While they are mindblasting and really crappy from dev's side, it shines when it comes to building software. So, 10 years old program still can usually be built (good luck to achieve this with Python) and if something goes wrong, build system only takes shell interpreter to start and give overall idea what's wrong with my environment. Then it is usually trivial to correct and there is very convenient logging which would tell what's wrong. SCons on other hand matches absolutely worst expectations each time you stumble into some trouble. So all this python crap must die by horrible death. Especially in build systems which are not supposed to be borked every year or two.

    Comment


    • #17
      Originally posted by 0xBADCODE View Post
      And to be honest, when it comes to building software, my favorite would be autotools. While they are mindblasting and really crappy from dev's side, it shines when it comes to building software. So, 10 years old program still can usually be built
      Ha! I laughed out loud at this. I deal daily with problems of version inconsistencies in autotools. autoreconf doesn't always do the job. And libtool is such a hacky mess, easily breaks in version changes.

      Sure, you can build a 10-year-old autotools Makefile, but you will likley need to install a 10-year-old autotools stack. And, you know, you can equally as easily install a 10-year-old Python if you have to.

      I actually used to think exactly like you, but life has taught me differently. In particular, Waf/Python made my work so much more pleasant. No turning back for me!

      Comment


      • #18
        Originally posted by emblemparade View Post
        Sure, you can build a 10-year-old autotools Makefile, but you will likley need to install a 10-year-old autotools stack.
        WTF?! Have you ever used autotools?

        The whole point of autotools is, when use them, they drop a "configure" file (and co) in your source that is entirely written in shell script and has mostly no other external dependency.
        Autotools are use to prepare the build system. Not actually to build it. When you run "./configure" on your source to configure and build it, you don't need autotools any more. You can ship your source in a .tar.bz2 and people will be able to use it directly. (as opposed to, e.g.: CMake, qmake, etc. where the user also needs them in order to build/compile).

        I DO HAVE several real world example of old, outdated and not supported anymore application, whose build system is autotools based, and the "./configure" script still runs 10 years later (well, of course, it's easy. It being written in pure shell and thus relying only on the single piece that has been more or less stable for the last couple of decades of Unix history).

        And, you know, you can equally as easily install a 10-year-old Python if you have to.
        getting an old python to work is a slightly more complicated task than getting an old shell script to work that doesn't rely on any shell dialect weirdness.


        I actually used to think exactly like you, but life has taught me differently. In particular, Waf/Python made my work so much more pleasant. No turning back for me!
        I'm financially supporting myself during my thesis by doing software maintenance and support at a large scientific cluster (technically I'm working as a researcher on a "developer position", but the support is what generates the most income). Tons of bioinformatics software here. Nearly every last one of them will try to either use the latest "build system du jour" or some hackish self-improvised solution, and are a mess to cleanly and properly deploy. The few autoconf-based are actually a blessing in comparison.

        Comment


        • #19
          Originally posted by DrYak View Post
          WTF?! Have you ever used autotools?
          You know, milleage may vary. There's no need to use abusive language and be so incredulous.

          I have plenty of example projects that do not build with recent versions of autotools. Recent ones I've worked on: libogg, pixman. For the following projects, I had to patch libtool due to limitations on portability: sdlmixer, libvorbis, cairo. Again, these are things I've just worked with recently, my history with autotools problems is long and painful.

          I'm glad things are working great for you. No build system is bulletproof, definitely not with version changes.

          Comment


          • #20
            Originally posted by przemoli View Post
            No, its not.
            yes it is

            Comment


            • #21
              Originally posted by pal666 View Post
              yes it is
              Thank you for that detailed rebuttal.

              Comment


              • #22
                Originally posted by DrYak View Post
                WTF?! Have you ever used autotools?

                The whole point of autotools is, when use them, they drop a "configure" file (and co) in your source that is entirely written in shell script and has mostly no other external dependency.
                Autotools are use to prepare the build system. Not actually to build it. When you run "./configure" on your source to configure and build it, you don't need autotools any more. You can ship your source in a .tar.bz2 and people will be able to use it directly. (as opposed to, e.g.: CMake, qmake, etc. where the user also needs them in order to build/compile).
                Assuming you use a tarball which has prebuilt configure script and that you don't need to patch any of the .am or .ac files. (or old .in). Then you'll need to dig up automake_1_10 or whatever.

                Comment

                Working...
                X