make-w32
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: suggestion: new make function


From: Luke Shumaker
Subject: Re: suggestion: new make function
Date: Sun, 25 Sep 2011 15:59:58 -0400
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Goj┼Ź) APEL/10.8 Emacs/23.3 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

At Sun, 25 Sep 2011 19:36:26 +0100,
Tim Murphy wrote:
> My apologies to Luke for forgetting "reply to all" and for forgetting
> my manners by using the word "sucks" when I should not have.

Now it's my turn to apologize, I just forwarded your original message
to me to the list. Sorry.

> > dumpOneLine = $(foreach item,$(2),echo -n '$(item) ' >> '$(1)')
> > dumpOnePerLine = $(foreach item,$(2),echo '$(item)' >> '$(1)')
> >
> > then use
> >  $(call dumpOnePerLine filename, $(list))
> 
> I use the foreach "trick" and I dislike it. It's complicated and
> tends to execute the shell 10x more than it needs to.  For small
> makefiles it doesn't matter but doing this for compiles (e.g. the ARM
> RVCT's multifile compilation option) in a large makefile is very
> unfortunate.

I have limited sympathy for this type of situation, "multifile
compilation" is against the general idea of make.

Certainly it does offer a speed improvement when compiling the whole
thing for the first time, but (in my experience) ends up costing the
developer more time as they wait for the entire thing to recompile
every time. I suppose there is something to be said for the end-user
compiling it, but having the end-user compile something theirself is
uncommon.

> I have wanted this feature in other situations too e.g.
> one which involved being able to create a persistent list of files
> across multiple builds
> for a named component no matter what platform it was
> built for and no matter whether any recipe actions happened or not.
> The only way to get what was needed turned out to be
> much more mindbending thanks to not having a function that appends to
> a file I find the code hard to understand every time I look at it and
> I know that anyone else who does is at risk of breaking it.
> 
> There are obviously a multitude of other uses like keeping debug
> information out of the main log - you name it.
> 
> Although you can try using  $(shell), you simply introduce a
> performance hit again which adds an hour onto some of my builds.
> 
>  I second the original poster of the message except I'd prefer
> something more like:
> 
> $(writefile filename,xxxxxxxxxxxxx)
> $(appendfile filename,xxxxxxxxxxxxx)
> 
> I'd get the one-item-per-line effect by inserting '\n' into the spaces
> in advance.
> 
> or perhaps:
> 
> $(withfile filename,w,$(info some stuff))
> $(withfile filename,a,$(foreach item,$(stuff),$(info $(item))))
> $(withfile filename,r+,$(info GET /)$(read RESPONSE))
> 
> ... acting as a redirector for stdout to the file and allowing one to
> perform quite complicated actions such as writing and reading from
> sockets although it is perhaps not all that "functional."

I find your suggestions more elagant than the original, they seem more
general purpose, and less "let's introduce this feature to get around
a specific problem". Of your two suggestions, I'd favor the "withfile"
option, it would be both more powerful, and doesn't introduce the
problem of trying to play with whitespace in make vairables.

I'm sure more discussion will need to happen before anything gets
merged, but I do like the idea of make-level IO redirection, but
mostly for debugging/logging, and storing persistant information.

~ Luke Shumaker
http://lukeshu.ath.cx



reply via email to

[Prev in Thread] Current Thread [Next in Thread]