Announcement

Collapse
No announcement yet.

Goals: Red Hat Developer Working On New Tool To Improve Upon Make

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

  • Goals: Red Hat Developer Working On New Tool To Improve Upon Make

    Phoronix: Goals: Red Hat Developer Working On New Tool To Improve Upon Make

    Longtime Red Hat developer Richard Jones has begun developing "Goals" as a new tool to improve upon Make, the common build automation tool...

    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
    At first I was all "Is this even necessary?" and then I made it to the part about scripting and whitespace handling and was all "About freakin time!!!".

    So I'm gonna keep reading on.

    Comment


    • #3
      Red Hat does maintain a copyright on the Goals files, so he is at least working on it partially in a Red Hat capacity.
      At first I thought they kept it closed source or under an extremely near-propietary license until $whatever happens. As a non-native English language speaker, it was very confusing to me. Good is at least GPLv2+.

      With CMake, Ninja, Meson... I see no reason for Goals to exist. This is NIH syndrome and another way to pollute development system with another build tool.

      Why not improve Make directly?

      Please prove me if i'm wrong.

      Comment


      • #4
        Originally posted by timofonic View Post

        Why not improve Make directly?

        Please prove me if i'm wrong.
        Legacy reasons I'd assume.

        Plus it just seems like a bad idea to change make to goals until they know all the bugs and kinks are worked out so they'd opted to wait until goals is more mature.

        If Goals can act as a drop-in replacement to Make, that makes it a better reason than Ubuntu, Unity and NIH syndrome as well as it won't pollute the development ecosystem since it would be a replacement and not an alternative.

        Comment


        • #5
          is the goal to get code pushed upstream or are they planning on forking make?

          Comment


          • #6
            Originally posted by timofonic View Post
            Why not improve Make directly?
            Why work on 40 year old codebase if you can avoid it? Make isn't a kernel.

            Comment


            • #7
              It appears to be written in OCaml (see the README file for a fairly long list of prerequisites). So here goes, IMO, #1 problem with make: portability, specifically, to Windows (while building GNU make on Windows is not difficult, it has issues with all those pesky spaces and colons in paths).

              While I agree a make replacement (along with autotools) is long overdue, I believe it should be written in one of the "base" languages that are native to all the platforms these days: C or C++. One such option is build2 (full disclosure: I am involved with the project). Here is an introduction to the build system, if anyone is interested: https://build2.org/build2/doc/build2...al.xhtml#intro

              Comment


              • #8
                Originally posted by timofonic View Post
                With CMake, Ninja, Meson... I see no reason for Goals to exist. This is NIH syndrome and another way to pollute development system with another build tool.
                CMake and Meson relies on Ninja/Make so they are not direct concurrent.
                With Ninja being one of the only alternative to make, I think Goals is a great idea.

                Comment


                • #9
                  I think his changes to the make syntax are reasonable; having make's text-expansion get mixed up with the shell's text-expansion is really annoying.

                  It would be nice to see a C/C++ equivalent of the cargo build system. As, in, doesn't have to be appropriate for all projects ever written, but is extremely low maintenance and parses the source to automatically resolve dependencies. Having GCC generate your make rules works for the most part, but debugging it is a huge PITA. This guide (http://make.mad-scientist.net/papers...cy-generation/) is an awesome example of that, but pay attention to how many special cases have to be dealt with.

                  Comment


                  • #10
                    To answer a few questions:

                    It's an experimental tool designed to explore new directions for a make-like tool. It absolutely does not work like the other tools people have mentioned. Free software continues to get better by people doing experiments, and we see what works and what doesn't work. Maybe goals won't work, in which case I'll have wasted a few weeks over Christmas. Maybe it'll be picked up in another tool. Maybe goals will become incredibly successful and displace those other tools (this is very unlikely). I'd advise people to actually watch the video, by comparing the tool to CMake and meson - which is literally mentioned in the first slide of the video - it shows you didn't do that.

                    Why not modify "make"? The syntax is totally different and has to be that way in order to solve the problems that make has. No such change would be acceptable to make.

                    The code is fully open source. The license is GPLv2.

                    Comment

                    Working...
                    X