Announcement

Collapse
No announcement yet.

Meson 0.50 Build System Brings PGI Compiler Support, Various Fortran Improvements & CUDA

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

  • #11
    Originally posted by andreano View Post
    I don't know in the case of Meson, but I don't think it is forking itself when descending into a subproject, so it should be in a position to at least detect a version conflict.
    i am not so sure about that.
    Originally posted by andreano View Post
    The solution in Rust/Cargo is to ship a cargo.lock file in the top-level project that "locks" everyone's versions to the ones that worked for you (or if you don't have such a file, it will be generated, detecting version conflicts along the way). Just saying it can be in scope for a buildsystem, and it's not unsolvable like with recursive buildsystems.
    Cargo is a package manager (and build-system, while Meson/CMake are Meta-Buildsystems, in the C/C++ World build2 would be a comparable all-in-one approach) and there is a separate top-level file cargo.lock exactly for the reason that you keep version information (and further build-configuration) for a build at one spot and not splattered across projects. Sometimes you have to accept that a solution was a horrible dead-end and no one wants go back there.

    C/C++ is notoriously fragmented, Conan steps in here to package libraries regardless of their buildsystem, taking care that all your dependencies have the right version and compatible configuration, and your equivalent of makefiles should be completely clean from those settings and just expect the dependencies to be built and available (other than defining the compatible range and default version of the dependencies). So your problems dont exponentially explode.

    Comment


    • #12
      Originally posted by Weasel View Post
      actually requires pretty recent python
      windows meson binaries come bundled with python. i'm sure something like that is doable on other oses

      Comment


      • #13
        Originally posted by discordian View Post
        You know, communicating back the compiler-specifics (default macros+include paths) would be nice, so an IDE can correctly resolve headers and symbols... for those fools who cross-compile most of the time.
        they generate compile_commands.json
        it's not default (in the sense of eclipse's built-in compiler settings), but you can make default out of it (add dummy source file, and in place of eclipse's command to get compiler specs put script which will transform commandline of dummy file and run it. you can even use some existing file instead of dummy)

        Comment


        • #14
          Originally posted by discordian View Post
          With meson such an extension is "upstream or bust", which is an insane model for the broad C/C++ Community
          i prefer meson to cmake, but i agree that all this "build system must not be turing complete" is misguided nonsense. build system is a program to build program

          Comment


          • #15
            Originally posted by andreano View Post

            I don't know in the case of Meson, but I don't think it is forking itself when descending into a subproject, so it should be in a position to at least detect a version conflict. The solution in Rust/Cargo is to ship a cargo.lock file in the top-level project that "locks" everyone's versions to the ones that worked for you (or if you don't have such a file, it will be generated, detecting version conflicts along the way). Just saying it can be in scope for a buildsystem, and it's not unsolvable like with recursive buildsystems.
            We've thought about that problem, meson only allows one copy of a subproject to be used for the entire project, subprojects must be "promoted" to the top build, there are a bunch of reasons for it, but one the principle reasons is to avoid linking two versions of the same library into a project.

            Comment


            • #16
              Originally posted by crymsonpheonix View Post
              Dude, you have got to work on your trolling, the implementation bit is an opinion, it's a good thing to troll over, the dependencies thing? meson only requires ninja and python 3.5 (from 2015). I'll give you a B for effort, but a C- for execution.
              "Troll" because I call it hot garbage and even give a reason why, really?

              lol at 2015, as if 3-4 years is long, wtf? Maybe if it was 2005, it would be more acceptable, but even that pales in comparison to autotools.

              Comment


              • #17
                Originally posted by discordian View Post
                Meson/CMake are Meta-Buildsystems (…) Conan steps in here to package libraries regardless of their buildsystem, taking care that all your dependencies have the right version and compatible configuration, and your equivalent of makefiles should be completely clean from those settings and just expect the dependencies to be built and available (other than defining the compatible range and default version of the dependencies).
                I get the impression that dcbaker just confirmed my point, that Meson actually is a package manager by your definition. I've yet to try Conan though, so I'll give you that.

                Originally posted by dcbaker
                We've thought about that problem, meson only allows one copy of a subproject to be used for the entire project, subprojects must be "promoted" to the top build, there are a bunch of reasons for it, but one the principle reasons is to avoid linking two versions of the same library into a project.
                Last edited by andreano; 03-12-2019, 04:28 PM.

                Comment


                • #18
                  Originally posted by andreano View Post
                  I get the impression that dcbaker just confirmed my point, that Meson actually is a package manager by your definition. I've yet to try Conan though, so I'll give you that.
                  Sigh, no, not even close, otherwise your project would just have one file that says get me these projects please (and their dependencies), and the rest of the project has no subprojects or references to source/binary locations, but just expects the libs and headers are ready to use. The package manager figures out where those should come from (based on additional configuration if necessary) and whether they should be built from source.

                  take a thorough look at conan.

                  Comment


                  • #19
                    Originally posted by discordian View Post
                    Sigh, no, not even close, otherwise your project would just have one file that says get me these projects please (and their dependencies), and the rest of the project has no subprojects or references to source/binary locations, but just expects the libs and headers are ready to use. The package manager figures out where those should come from (based on additional configuration if necessary) and whether they should be built from source.
                    That's mostly, but not completely true, subprojects can be vendored, though we generally discourage that practice. have a look at our wrap-db. The biggest difference I see between our process and what conan does (and you like), is that we configure and build all subprojects (both local and fetched via wraps) in the same build process as the main project. This has some nice properties like ensuring that the whole project is built with the same compiler, linked against the same crt on windows, has the same debug flags, and that you don't end up linking against two versions of the same library.

                    If you like conan and it fits your workflow use it. Not everyone builds software the same way.

                    Also, I forgot to mention earlier, there was a bunch of work in 0.50 around meson's introspection API specifically driven by a person working on an IDE plugin for meson (QTCreator IIRC). So hopefully you'll be able to get the information back from the compiler you want for your IDE soonish.

                    Comment


                    • #20
                      Originally posted by dcbaker View Post
                      That's mostly, but not completely true, subprojects can be vendored, though we generally discourage that practice. have a look at our wrap-db. The biggest difference I see between our process and what conan does (and you like), is that we configure and build all subprojects (both local and fetched via wraps) in the same build process as the main project. This has some nice properties like ensuring that the whole project is built with the same compiler, linked against the same crt on windows, has the same debug flags, and that you don't end up linking against two versions of the same library.
                      Thats why conan puts a hash over the options, so that you end up with the right prebuild binary, see for ex zlib: https://bintray.com/conan-community/...able%2Fpackage (see the included conaninfo.txt).
                      you can - by your choice - get prebuild packages from a cache on your local computer, from an in-house conan server, an public server or automatically or explicitly build any dependency from source. The only thing that's not handled well so far is that I would like to be able to pick native dependencies (installed packages or using native managers like apt-get).

                      Originally posted by dcbaker View Post
                      If you like conan and it fits your workflow use it. Not everyone builds software the same way.
                      No, and conan doesnt enforce and cripple you in anyway.
                      Its kinda the same with branches from CVS and branches ala git (that can work decentral), one of them is an order of magnitude more useful.
                      As example, you build 5 GUI apps using QT5 for an embedded target, how would you orchestrate that if QT5 is a meson package (without using conan)?
                      Will meson dictate your workflow, as in having one mega-project so QT5 wont be rebuilt from scratch over-and-over?

                      With conan you can work any way you want, the system allows (but doesnt dictate) to reuse cached/prebuild versions of QT5.
                      And with CMake you have the QT5 helpers available in the installed package, if QT6 mixes things up (like a different moc-tool) you get new helper with the package and ideally wont change a thing, with meson you wait till upstream added the new QT6 compatible modul?
                      How are things if your dependency is not popular enough to be added as meson module?

                      Originally posted by dcbaker View Post
                      Also, I forgot to mention earlier, there was a bunch of work in 0.50 around meson's introspection API specifically driven by a person working on an IDE plugin for meson (QTCreator IIRC). So hopefully you'll be able to get the information back from the compiler you want for your IDE soonish.
                      I made the decision around two years ago, and the lack of being able to write a build-system module that can be reused (and doesnt have to be copied everywhere) for multiple projects doesnt make me considering changing. Correct me if any understanding of the above is wrong, I stopped looking closely.

                      To me you are doing what SVN did: re-implement a nicer looking CVS, and don't question anything. build2 would be more like git, but there are alot of things I dont like about it so far. No matter how the build-system struggle will end, using conan atleast frees me from that choice (and is heads and heels above the other solutions).

                      Comment

                      Working...
                      X