[HN Gopher] Tired of Makefiles
       ___________________________________________________________________
        
       Tired of Makefiles
        
       Author : fanf2
       Score  : 21 points
       Date   : 2024-05-13 21:24 UTC (1 hours ago)
        
 (HTM) web link (dmitryfrank.com)
 (TXT) w3m dump (dmitryfrank.com)
        
       | verdverm wrote:
       | Author is now trying Bazel
       | 
       | I'm going the Dagger path
       | 
       | This CNCF talk covers both:
       | https://www.youtube.com/watch?v=nZLz0o4duRs
        
         | hoherd wrote:
         | Author tried bazel 8 years ago, which is when the article was
         | written. Judging by his GH repos, he's still using Makefiles.
         | 
         | https://github.com/dimonomid/bulgaria-freelance-taxes/blame/...
        
           | amtamt wrote:
           | Anyone not working alone, not working on his own projects
           | only, will end up having to use tools created ages ago, but
           | refined gradually, how ever clunky the usage feels along the
           | usage journey.
        
       | willcipriano wrote:
       | I like makefiles not as a build tool but as a way to put better
       | ui around long difficult to type/remember commands on the repo
       | 
       | make up
       | 
       | make down
       | 
       | make clean
       | 
       | make upgrade
       | 
       | make migrate
       | 
       | Easier than having to think about it
        
         | massysett wrote:
         | Couldn't you do this with shell scripts? Make just runs
         | commands anyway. If you're not using make's dependency-tracking
         | features, might as well just use the shell directly and use the
         | simplest tool for the job.
        
           | xmprt wrote:
           | make still has a better UI than shell scripts. With shell
           | scripts you have to maintain multiple files whereas a
           | Makefile has all the scripts in a single file.
        
             | t3rra wrote:
             | wth. makefile can include other makefiles.
        
             | edflsafoiewq wrote:
             | Why is that a better UI?
        
             | SahAssar wrote:
             | No you don't. I like makefiles because of the dependencies
             | between targets but for simple multi-target things I still
             | do shell scripts like                   mything() {
             | # ...         }              otherthing() {           # ...
             | }              if [ $# -eq 0 ]; then             echo
             | "Usage: ./run.sh [mything, otherthing]"             exit 1
             | fi              "$@"
        
           | cassianoleal wrote:
           | I'm not GP but:
           | 
           | Make gives me a single, predictable and stable interface to
           | the repo.
           | 
           | From the root of the repo, I can type `make <tab>` and get a
           | list of available tasks. Alternatively, there's a Makefile on
           | the root.
           | 
           | With scripts, I need to type... what? `./<tab>` and look for
           | clues? Maybe the scripts are in `scripts/`, maybe they're in
           | `build/`, maybe they're in `ci/`...
           | 
           | Even if I know where the scripts are, `make task` is quicker
           | and easier to type than `./scripts/task.sh`.
           | 
           | One could just use a make task to call a script, which I have
           | done, but in most cases if you do that, what's the point of
           | the script?
        
         | deathanatos wrote:
         | I find `just` to be better suited than `make` for this use
         | case: https://github.com/casey/just
         | 
         | The sibling's comment (re. just shell in files) is good too,
         | and often I'll put all the various commands into a subdir, and
         | `just` is just an interface to that, _particularly_ so if a
         | given script /command gets complex.
         | 
         | Then, `just` is really a signal "hey, this repo supports this
         | interface" and things like `just -l` for discoverability.
        
           | cassianoleal wrote:
           | I have never used just, but one major advantage of make is
           | that it pretty much exists everywhere - I can assume it's
           | present and I'll be right almost every time.
        
           | eikenberry wrote:
           | Just looks nice but isn't very prevalent yet. One of make's
           | strengths is that it is everywhere.
        
       | __MatrixMan__ wrote:
       | I was describing nix to a friend and he offered this summary:
       | 
       | > it's make for grownups
        
       | smlavine wrote:
       | Sounds like he wants the -B option.
        
       | pheggs wrote:
       | I personally had the complete opposite experience with make, the
       | more I work with it the more I like it. You have to keep things
       | simple, and IMO thats a good thing.
       | 
       | I also feel like good makefiles are usually very small and dont
       | need much tweaking once they are in place.
       | 
       | I dont know your project structure but it may be advisable to
       | actually split those builds completely or merge them together.
       | 
       | For the rebuilds you can just use the -B switch.
       | 
       | I am personally also a big fan of implicit compile and link
       | rules, but I guess thats a matter of taste
        
       | silverwind wrote:
       | Make would be so great if it had:
       | 
       | 1. a way to track target freshness based on content hash
       | 
       | 2. a way to declare variable values as dependencies
        
       | hggh wrote:
       | (2016)
        
       | xn wrote:
       | I tend to use redo (https://redo.readthedocs.io/en/latest/) for
       | new projects. I find it particularly well suited for multi-step
       | data processing workflows, where I might want to retrieve new
       | data daily or hourly, or when I switch from one environment to
       | another.
        
       ___________________________________________________________________
       (page generated 2024-05-13 23:01 UTC)