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

  • #11
    Originally posted by skeevy420 View Post

    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.
    I can't find any statement reading the notes and README that Goals is a drop-in replacement to Make.

    Also it's not clear but maybe it will come with dependencies to OCaml and Perl. This will just stress the developer system setup already crowded with libraries and version requirements.

    I would expect that a so basic build tool like this doesn't have intrusive dependencies and would be a simple standalone executable built in a compiled language like C, C++, Go or Rust. Also don't forget Windows and others SOs where make works.

    The problems that it solves are the same as 70's Make putting it far distant of modern turbo charged build/package/release tools like maven/grade/cargo/npm/etc...

    So what we can think about it:
    • NIH ?
    • YABT ?
    What you think about?

    Comment


    • #12
      Originally posted by juarezr View Post

      I can't find any statement reading the notes and README that Goals is a drop-in replacement to Make.

      Also it's not clear but maybe it will come with dependencies to OCaml and Perl. This will just stress the developer system setup already crowded with libraries and version requirements.

      I would expect that a so basic build tool like this doesn't have intrusive dependencies and would be a simple standalone executable built in a compiled language like C, C++, Go or Rust. Also don't forget Windows and others SOs where make works.

      The problems that it solves are the same as 70's Make putting it far distant of modern turbo charged build/package/release tools like maven/grade/cargo/npm/etc...

      So what we can think about it:
      • NIH ?
      • YABT ?
      What you think about?
      There is a limitation of all current build system (at least for what I'm aware of): the only thing they can check is the timestamp.

      For example, if I have a subproject with reproducible builds, and the main project depends on its output.
      Someday I found a typo in the comment of the subproject, I fixed it, and then I build.
      Ideally nothing in the main project should run at all, but with timestamp, hmm, you know what would happen.
      (This is simplified from a real-world case, and I even coded up a "cache" script to avoid duplicated task execution.)
      This case is described by the TACTIC PROBLEM section.

      Ideally this new build system is a standalone executable, but consider the labouring work (e.g. string manipulations) I would like to see a script based solution first as the fast prototype.

      Comment


      • #13
        Originally posted by juarezr View Post

        I can't find any statement reading the notes and README that Goals is a drop-in replacement to Make.

        Also it's not clear but maybe it will come with dependencies to OCaml and Perl. This will just stress the developer system setup already crowded with libraries and version requirements.

        I would expect that a so basic build tool like this doesn't have intrusive dependencies and would be a simple standalone executable built in a compiled language like C, C++, Go or Rust. Also don't forget Windows and others SOs where make works.

        The problems that it solves are the same as 70's Make putting it far distant of modern turbo charged build/package/release tools like maven/grade/cargo/npm/etc...

        So what we can think about it:
        • NIH ?
        • YABT ?
        What you think about?
        Neither can I, but I did say "If Goals can be a drop in replacement". IF is the keyword.

        I was also wondering about the dependencies requirement too.

        I also saw that "I hope it's like Cargo" post and thought to myself: "Iz you a tard?" due to all the places and languages that make is expected to work with.

        It does aim to solve shell and scripting issues without requiring people to know about hacks like .PHONY and whatnot. If it can do that while acting as a drop-in replacement, then it is worth the effort and will have mine and a lot of other's gratitude. There's another IF there.

        What I think about? Let's not go there

        Comment


        • #14
          Originally posted by juarezr View Post

          I can't find any statement reading the notes and README that Goals is a drop-in replacement to Make.

          Also it's not clear but maybe it will come with dependencies to OCaml and Perl. This will just stress the developer system setup already crowded with libraries and version requirements.

          I would expect that a so basic build tool like this doesn't have intrusive dependencies and would be a simple standalone executable built in a compiled language like C, C++, Go or Rust. Also don't forget Windows and others SOs where make works.

          The problems that it solves are the same as 70's Make putting it far distant of modern turbo charged build/package/release tools like maven/grade/cargo/npm/etc...

          So what we can think about it:
          • NIH ?
          • YABT ?
          What you think about?
          I agree, but...

          YABT? You Are Being Trolled?

          Comment


          • #15
            Originally posted by skeevy420 View Post
            I also saw that "I hope it's like Cargo" post and thought to myself:
            Every day we stray further from something something...

            Comment


            • #16
              I'm not saying I would like goals to be like Cargo, I'm saying it would be nice for a separate tool to fill that niche for C/C++. Make fails at that purpose, and presumably goals would as well. But that's okay, because that's not the purpose it was made for.

              Comment


              • #17
                Originally posted by Blahblah View Post
                I'm not saying I would like goals to be like Cargo, I'm saying it would be nice for a separate tool to fill that niche for C/C++. Make fails at that purpose, and presumably goals would as well. But that's okay, because that's not the purpose it was made for.
                I agree with that 100%.

                It doesn't help that my memory sucks and I was too lazy to re-read what you posted and instead remembered it incorrectly...I'm a bit embarrassed to admit that I can forget key details that fast.

                Comment


                • #18
                  What I would change is not the syntax, but its meaning, to be more sane.

                  - Every variable in Make is semantically an array, yet Make manages to not support arrays.
                  - Not invoke the shell implicitly.
                  - Handle recursion holistically.
                  Last edited by andreano; 14 January 2020, 02:35 PM.

                  Comment


                  • #19
                    Looks interesting.

                    I admit though when I first saw the post, my first thought was "they're going to incorporate Make into systemd."

                    Comment


                    • #20
                      Just https://github.com/casey/just is another take on an updated Make, written in Rust.

                      Comment

                      Working...
                      X