Announcement

Collapse
No announcement yet.

The Meson Build System Is Being Fitted For The X.Org Server

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

  • The Meson Build System Is Being Fitted For The X.Org Server

    Phoronix: The Meson Build System Is Being Fitted For The X.Org Server

    Longtime X.Org developer Eric Anholt who previously worked for Intel and is now working for Broadcom on the open-source VC4 driver stack is working to add the Meson build system support for the xorg-server...

    http://www.phoronix.com/scan.php?pag...-Meson-Fitting

  • #2
    Maybe they should revert to imake. At least it worked on the BSDs.

    Comment


    • #3
      Why doesn't meson work on BSD? It's Python code.

      It would seem that this conversion is a good thing - if only stuff like the following disappears: (from the blog post)
      So far the only stumbling block for the meson conversion of the X Server is the X.org sdksyms.c file. It's the ugliest part of the build -- running the C preprocessor on a generated .c that #includes a bunch of .h tiles, then running the output of that through awk and trying to parse C using regular expressions. This is, as you might guess, somewhat fragile.

      Comment


      • #4
        While I realize not everyone wants FUSE as a dependency to run something like tup, I must admit I don't what's attractive about the syntax for Meson. In that area, I honestly find Ninja build files even more readable.

        Can anyone provide a reasonable readable example with Meson? They don't provide one on their website.

        Comment


        • #5
          If the X.Org code base is massive, maybe it could be made smaller?
          Remove old, legacy stuff. Remove unused stuff, remove deprecated stuff.
          What could be removed? DRI1, DRI2? Old input methods now that there is libinput?
          Is anything being removed?

          With this new build system could there be an option to build a minimal X only for XWayland?
          Or one to build a minimal X only for GTK3 and Qt5 applications for those who don't need support legacy GTK2 and Qt3 and Qt4 applications?

          Comment


          • #6
            Originally posted by oleid View Post
            Why doesn't meson work on BSD? It's Python code.
            It's not that meson doesn;t work on BSD. It's that BSD would need to be rewritten to have Python built during its build bootstrap phase.

            Comment


            • #7
              Originally posted by necrophcodr View Post
              While I realize not everyone wants FUSE as a dependency to run something like tup, I must admit I don't what's attractive about the syntax for Meson. In that area, I honestly find Ninja build files even more readable.

              Can anyone provide a reasonable readable example with Meson? They don't provide one on their website.

              Here is a real world example: https://github.com/matthiasclasen/gr...er/meson.build

              The syntax is very simple and does nothing fancy and isn't turing complete.

              Comment


              • #8
                Originally posted by bregma View Post

                It's not that meson doesn;t work on BSD. It's that BSD would need to be rewritten to have Python built during its build bootstrap phase.
                Leaving aside the personal views of the particular BSD flavours devs, would this be such a difficult thing on a technical level?

                Comment


                • #9
                  Originally posted by uid313 View Post
                  If the X.Org code base is massive, maybe it could be made smaller?
                  Remove old, legacy stuff. Remove unused stuff, remove deprecated stuff.
                  What could be removed? DRI1, DRI2? Old input methods now that there is libinput?
                  Is anything being removed?

                  With this new build system could there be an option to build a minimal X only for XWayland?
                  Or one to build a minimal X only for GTK3 and Qt5 applications for those who don't need support legacy GTK2 and Qt3 and Qt4 applications?
                  I'm pretty sure that old, legacy stuff is part of the protocol. If you start removing that, then you break compatibility with X11
                  Last edited by bachchain; 03-28-2017, 11:23 AM.

                  Comment


                  • #10
                    Originally posted by bachchain View Post

                    I'm pretty sure that old, legacy stuff is part of the protocol. If you start removing that, then you break compatibility with X11
                    Yeah, that is true.
                    But there could be one compile option to compile the full stack with all the legacy parts if you really want wayback compatibility.

                    Then there could be a compile option to compile a minimalist stack without the legacy parts, and if that breaks compatibility with X11 that is fine for me, as long as it works with GTK 3 and Qt 5 applications. If decade old stuff don't work that is fine, at least I get something faster, leaner, cleaner and with reduced attack surface.

                    Comment

                    Working...
                    X