Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 22

Thread: Meson: A Next-Gen Build System Showing Promise

  1. #11
    Join Date
    Jan 2014
    Posts
    34

    Default

    Quote Originally Posted by Alliancemd View Post
    There is also Gradle which is way more powerful and stable...
    That is a build system, not a build system generator FYI. CMake, GYP and such merely export makefiles, ninja files or IDE files. Whereas Gradle is a full-blown framework.

  2. #12
    Join Date
    Jan 2014
    Posts
    34

    Default

    Gradle is good. A little bit too much to install though, 50MB on arch aur repo wtf is in that packet?

  3. #13
    Join Date
    Jan 2011
    Posts
    419

    Default

    Meson seemed interesting until I saw the last slide of the lightning talků

  4. #14
    Join Date
    Aug 2011
    Posts
    98

    Default

    Quote Originally Posted by emblemparade View Post
    It is exactly true that it's ridiculous to try to incorporate a dedicated programming language into a build system when there already are terrific dynamic languages out there, such as Python. With Waf, it's a pleasure to be able to do everything I need to do in my build script. And of course its built-in API handles so many important (and complicated) build tasks for me. What would Meson do differently?
    To me, a basic test as to whether a programming language is too verbose to be fun to use is whether it makes sense to script the build system in the language itself. Ant and Maven are clunky, but they're a world better than writing your Java build configuration in Java. So Java, despite any other merits it might have, fails the fun-to-use test.

    Groovy (Gradle) is a pleasure to use in the build system, and so is Clojure (Leiningen). Not coincidentally, given the choice I would rather work on Groovy or Clojure projects than on pure Java.

    I can't imagine scripting my C or C++ builds in those languages. Yikes. But for example the attempted replacements Go and D both compile very rapidly and make a lot of common tasks syntactically simpler than equivalent C++ code, so I bet scripting your Go or D builds in those respective languages is feasible.

  5. #15
    Join Date
    Jun 2011
    Posts
    1,090

    Default

    While we're on the topic of build systems I haven't really played with it yet I kinda like the ideas behind Qbs

    http://qt-project.org/doc/qbs-1.2/la...roduction.html

  6. #16
    Join Date
    Jun 2012
    Posts
    328

    Default 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.

  7. #17
    Join Date
    Jan 2014
    Posts
    97

    Default

    Quote 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!

  8. #18
    Join Date
    Apr 2008
    Posts
    182

    Default

    Quote 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.

  9. #19
    Join Date
    Jan 2014
    Posts
    97

    Default

    Quote 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.

  10. #20
    Join Date
    Apr 2013
    Posts
    352

    Default

    Quote Originally Posted by przemoli View Post
    No, its not.
    yes it is

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •