Qake: GNU Make-based build system with a different approach

#1

Post by nkurz » Tue, Nov 04, 2014, 1:47 AM UTC

Qake: GNU Make-based build system with a different approach
github.com

Re: Qake: GNU Make-based build system with a different approach

#2

Post by vezzy-fnord » Tue, Nov 04, 2014, 2:42 AM UTC

Another alternative to make is mk [1], originally written for Version 10 Unix before becoming the standard build tool in Plan 9 and Inferno, and later ported to Linux/BSD/OS X as part of plan9port [2].

[1] http://doc.cat-v.org/plan_9/4th_edition/papers/mk

[2] http://swtch.com/plan9port/man/man1/mk.html

Re: Qake: GNU Make-based build system with a different approach

#3

Post by Tobani » Tue, Nov 04, 2014, 2:55 AM UTC

  Goal
  
  The user is supposed to be never needing to call clean goal.

Does this track build tools also? If you upgrade a compiler and some intermediate binary format changes, will it automatically clean up those stale files?

Re: Qake: GNU Make-based build system with a different approach

#4

Post by codygman » Tue, Nov 04, 2014, 2:59 AM UTC

I've always wondered why Shake[0] wasn't more popular. Anyone not like Shake or know why others don't, or is this just a case of not being known?

0: https://github.com/ndmitchell/shake

Re: Qake: GNU Make-based build system with a different approach

#5

Post by Tobani » Tue, Nov 04, 2014, 3:17 AM UTC

codygman wrote: post #4

I've always wondered why Shake[0] wasn't more popular. Anyone not like Shake or know why others don't, or is this just a case of not being known? 0: https://github.com/ndmitchell/shake

The Manual[0] contains an intro that isn't particularly compelling. It contains things like:

   phony "clean" $ do
        putNormal "Cleaning files in _build"
        removeFilesAfter "_build" ["//*"]

Which would be the make equivalent:

  clean:
    rm _build/*

Now that's obviously the trivial example. But its not trivial to drop make entirely for something entirely different. A make solution can slowly get more complicated over time. It looks like shake might be useful for something really big. I can't quite tell where the investment of learning a new tool and re-develop something(that works well enough) would pay off.

0: https://github.com/ndmitchell/shake/blob/master/docs/Manual....

Re: Qake: GNU Make-based build system with a different approach

#6

Post by q3k » Tue, Nov 04, 2014, 3:32 AM UTC

    wget --no-check-certificate https://... - | sh

Might as well not have that https in there at all... sigh.

Re: Qake: GNU Make-based build system with a different approach

#7

Post by rraval » Tue, Nov 04, 2014, 3:36 AM UTC

codygman wrote: post #4

I've always wondered why Shake[0] wasn't more popular. Anyone not like Shake or know why others don't, or is this just a case of not being known? 0: https://github.com/ndmitchell/shake

In my case, I was entirely unaware of Shake's existence. The no-nonsense support for file oriented workflows is the most compelling feature of Makefiles for me.

In that regard, Shake seems really compelling. It supports the file oriented nature of my build system. It's backed by an actual programming language, with lexical scoping, functions, a module system... all the things that suck about Makefiles.

Most importantly, it solves the one thing that drives me up the wall with Makefiles: supporting custom command line arguments sanely. I detest typing `make web TARGET=prod` and `shakeArgsWith` seems like it provides the flexibility of specifying targets and flags from custom command line arguments.

Thanks for this, I'm going to try and convert a few non trivial Makefiles to Shake. Any cons I should be aware of?

Re: Qake: GNU Make-based build system with a different approach

#8

Post by nmcfarl » Tue, Nov 04, 2014, 3:40 AM UTC

q3k wrote: post #6

wget --no-check-certificate https://... - | sh Might as well not have that https in there at all... sigh.

It's a self-signed cert - and just as encrypted as it would be with a traditionally signed cert.

This is the half of SSL that I care about - I really don't care if you handed your money over to some organization that verified you have a working phone number.

--

Actually it doesn’t appear to be a self-signed cert in this case - or even necessary. That cert is playing fine with both safari, and GNU Wget 1.14.

Re: Qake: GNU Make-based build system with a different approach

#9

Post by pyre » Tue, Nov 04, 2014, 3:52 AM UTC

nmcfarl wrote: post #8

q3k wrote: post #6

wget --no-check-certificate https://... - | sh Might as well not have that https in there at all... sigh.

It's a self-signed cert - and just as encrypted as it would be with a traditionally signed cert. This is the half of SSL that I care about - I really don't care if you handed your money over to some organization that verified you have a working phone number. -- Actually it doesn’t appear to be a self-signed cert in this case - or even necessary. That cert is playing fine with both safari, and GNU Wget 1.14.

Older versions of wget didn't like wildcard certs (IIRC). I remember this being an issue around the time that github.com when https-only a few years ago.

It's possible that this is necessary here (on older versions of wget), or that using '--no-check-certificate' is a bit of a cargo-cultism by the author (who learned to use it, but doesn't know why and when usage makes sense).

Re: Qake: GNU Make-based build system with a different approach

#10

Post by asveikau » Tue, Nov 04, 2014, 4:10 AM UTC

nmcfarl wrote: post #8

q3k wrote: post #6

wget --no-check-certificate https://... - | sh Might as well not have that https in there at all... sigh.

It's a self-signed cert - and just as encrypted as it would be with a traditionally signed cert. This is the half of SSL that I care about - I really don't care if you handed your money over to some organization that verified you have a working phone number. -- Actually it doesn’t appear to be a self-signed cert in this case - or even necessary. That cert is playing fine with both safari, and GNU Wget 1.14.

I guess you won't mind when I put my own self-signed cert there, then.