Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #2137 > unrolled thread

Using Make for workflow control

Back to article view | Back to comp.misc

Contents

  Using Make for workflow control RS Wood <rsw@therandymon.com> - 2014-03-30 14:28 +0000
    Re: Using Make for workflow control despen@verizon.net (Dan.Espen) - 2014-03-30 13:39 -0400
    Re: Using Make for workflow control Rich <rich@example.com> - 2014-03-30 21:54 +0000
    Re: Using Make for workflow control Huge <Huge@nowhere.much.invalid> - 2014-03-31 08:40 +0000
    Re: Using Make for workflow control scott@alfter.diespammersdie.us (Scott Alfter) - 2014-03-31 17:43 +0000
    Re: Using Make for workflow control Theo Markettos <theom+news@chiark.greenend.org.uk> - 2014-04-01 23:40 +0100
      Re: Using Make for workflow control despen@verizon.net (Dan.Espen) - 2014-04-01 20:00 -0400

#2137 — Using Make for workflow control

Interesting article, linked to from Hacker News, about using Make for
workflows that don't necessarily involve building binaries or libraries.

http://bost.ocks.org/mike/make/

I'll have to look into it - seems like a lot of work to learn, but
potentially worth it.  Automation of processes is good for sanity.

[toc] | [next] | [standalone]

#2142

RS Wood <rsw@therandymon.com> writes:

> Interesting article, linked to from Hacker News, about using Make for
> workflows that don't necessarily involve building binaries or libraries.
>
> http://bost.ocks.org/mike/make/
>
> I'll have to look into it - seems like a lot of work to learn, but
> potentially worth it.  Automation of processes is good for sanity.

Preaching to the choir.  Make has all kinds of uses.
Here's a simple Makefile for uploading to a web site:


UP_SITE:=mywebsite.net
uploads:=$(wildcard $.html) $(wildcard *.png)

targets:=$(addsuffix .uploaded,$(uploads))

all: $(targets)

define install_html
(\
echo -e "binary\n"\
 "put $(subst .uploaded,,$@)\n"\
 "close\n"\
 "quit\n"\
 ) | ftp $(UP_SITE)
endef

%.uploaded: %
	$(install_html)
	echo "`date`" > $@

clean:
	rm *.uploaded

-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#2145

RS Wood <rsw@therandymon.com> wrote:

> Interesting article, linked to from Hacker News, about using Make for
> workflows that don't necessarily involve building binaries or
> libraries.

> http://bost.ocks.org/mike/make/

> I'll have to look into it - seems like a lot of work to learn, but
> potentially worth it.  Automation of processes is good for sanity.

Actually, for simple situations, it is not much to learn.

Two rules suffice:

1) target rules - name of target <colon> things target depends upon

i.e.:


2) "how to create things lines" - always begin with an actual tab
character.

i.e.:

Put the two together:


final.product: partial.product.1 partial.product.2 partial.product.3
	generate --output final.product --input partial.product.1 partial.product.2 partial.product.3


And you have a very simple makefile.

[toc] | [prev] | [next] | [standalone]

#2154

On 2014-03-30, RS Wood <rsw@therandymon.com> wrote:
> Interesting article, linked to from Hacker News, about using Make for
> workflows that don't necessarily involve building binaries or libraries.
>
> http://bost.ocks.org/mike/make/
>
> I'll have to look into it - seems like a lot of work to learn, but
> potentially worth it.  Automation of processes is good for sanity.

I've been doing this for years. In fact, I don't think I've ever written
a Makefile that actually builds software... (I stopped being a developer
before I ever came across Unix)

-- 
Today is Setting Orange, the 17th day of Discord in the YOLD 3180
“Stupidity cannot be cured. Stupidity is the only universal capital crime;
 the sentence is death. There is no appeal, and execution is carried out
                 automatically and without pity.”

[toc] | [prev] | [next] | [standalone]

#2178

In article <lh99me$fsm$1@solani.org>, RS Wood  <randy@therandymon.com> wrote:
>Interesting article, linked to from Hacker News, about using Make for
>workflows that don't necessarily involve building binaries or libraries.
>
>http://bost.ocks.org/mike/make/
>
>I'll have to look into it - seems like a lot of work to learn, but
>potentially worth it.  Automation of processes is good for sanity.

I've used make for a long time to manage DNS updates.  I suspect it's my use
of djbdns that encourages this behavior.

  _/_
 / v \ Scott Alfter (remove the obvious to send mail)
(IIGS( http://alfter.us/            Top-posting!
 \_^_/                              >What's the most annoying thing on Usenet?

[toc] | [prev] | [next] | [standalone]

#2196

RS Wood <rsw@therandymon.com> wrote:
> Interesting article, linked to from Hacker News, about using Make for
> workflows that don't necessarily involve building binaries or libraries.
> 
> http://bost.ocks.org/mike/make/
> 
> I'll have to look into it - seems like a lot of work to learn, but
> potentially worth it.  Automation of processes is good for sanity.

One situation I found to be troublesome is make assumes files are processed
by taking file A and running it through a rule to make file B.  This doesn't
work if A and B are the same file.  For example:

sed -i s/example/example2/g somefile

will replace 'example' in somefile with 'example2'.  If it runs twice
it makes 'example22', which isn't what you want.

Obviously this is a contrived example, but the general problem is Make uses
the file dates to work out whether to run a process or not.  In the above
case Make won't run the rule because it compares the timestamps of
'somefile' and 'somefile' and discovers they're the same.  The output
'somefile' isn't out of date with respect to the input 'somefile' so the
step never happens.

If you force the step to happen by not declaring the dependency there is a
risk it'll happen twice.  Even if that isn't a problem, make has no way of
knowing that the step doesn't need doing - so it will do it every time.
This is bad, especially if it'll cause lots of things downstream to rerun.

While this is fine if you can make sure your tools use a file A -> file B
paradigm, some tools don't work like that.  The workarounds get messy.

Theo

[toc] | [prev] | [next] | [standalone]

#2199

Theo Markettos <theom+news@chiark.greenend.org.uk> writes:

> RS Wood <rsw@therandymon.com> wrote:
>> Interesting article, linked to from Hacker News, about using Make for
>> workflows that don't necessarily involve building binaries or libraries.
>> 
>> http://bost.ocks.org/mike/make/
>> 
>> I'll have to look into it - seems like a lot of work to learn, but
>> potentially worth it.  Automation of processes is good for sanity.
>
> One situation I found to be troublesome is make assumes files are processed
> by taking file A and running it through a rule to make file B.  This doesn't
> work if A and B are the same file.  For example:
>
> sed -i s/example/example2/g somefile

somefile.ok: somefile
        sed -i s/example/example2/g somefile
        grep example2 somefile && echo 'somefile is okay' > somefile.ok

(not tested)

> will replace 'example' in somefile with 'example2'.  If it runs twice
> it makes 'example22', which isn't what you want.

I think you need a better example.
One that actually does something useful.
When I tried to make your example useful,
I came to a solution.

> Obviously this is a contrived example, but the general problem is Make uses
> the file dates to work out whether to run a process or not.  In the above
> case Make won't run the rule because it compares the timestamps of
> 'somefile' and 'somefile' and discovers they're the same.  The output
> 'somefile' isn't out of date with respect to the input 'somefile' so the
> step never happens.

Yes, but if you check that you did what you wanted to the file,
a solution appears.

> If you force the step to happen by not declaring the dependency there is a
> risk it'll happen twice.  Even if that isn't a problem, make has no way of
> knowing that the step doesn't need doing - so it will do it every time.
> This is bad, especially if it'll cause lots of things downstream to rerun.
>
> While this is fine if you can make sure your tools use a file A -> file B
> paradigm, some tools don't work like that.  The workarounds get messy.

I don't think particularly messy.
In the real world, I'd have the .ok (above) filed away in a sub-directory.

-- 
Dan Espen

[toc] | [prev] | [standalone]

Back to top | Article view | comp.misc

csiph-web