--- Begin Message ---
Re: suggestion: new make function
Sun, 25 Sep 2011 19:27:42 +0100
I use the foreach "trick" and it utterly sucks. 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 wanted this feature in other situations too e.g.
one which involved being able to create a persistent list of files
seen in the build of a named component no matter what platform it was
built for and 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:
I'd get the one-item-per-line effect by inserting '\n' into the spaces
$(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."
On 25 September 2011 18:41, Luke Shumaker <address@hidden> wrote:
> At Tue, 20 Sep 2011 12:09:42 -0700,
> Lawrence Ibarria wrote:
>> I have often hit problems with the limit of command line lengths
>> many shells have (CMD.EXE in Windows in my case).
>> This is a common case with few solutions, I have searched around:
>> I would like to propose a couple new functions in make that can help
>> work around this problem.
>> $(dumpOneLine filename, $(list))
>> $(dumpOnePerLine filename, $(list))
>> The idea here is to ask make to dump into a file (either on a single
>> line or each element of the list in a new line) all the contents of
>> a list.
>> This function specifically does not use the shell, I expect make to
>> implement it with fopen directly. Once all the contents of a long
>> list in make are in a file, programs (such as linker, or compiler)
>> can use that file as input.
>> I do not know how to address specifics such as variable expansion on
>> the list (I'd suggest no variable expansion at all, create a new
>> list for that).
>> What do you think?
>> -- Lawrence
> I vote 'no'. This can easily be implemented in your
> Makefile. (assuming no single list item breaks the limit)
> dumpOneLine = $(foreach item,$(2),echo -n '$(item) ' >> '$(1)')
> dumpOnePerLine = $(foreach item,$(2),echo '$(item)' >> '$(1)')
> then use
> $(call dumpOnePerLine filename, $(list))
> I don't know if '>>' works the same in CMD.EXE as it does in Bash
> (concatentate stdout of the command on the left to the file on the
> right), or if echo behaves similarly ('-n' to make it ommit the
> trailing newline), but something like it should work.
> Further, this is frequently the WRONG way to do it. The example on the
> page you linked to is terrible (surprising, I've come to expect better
> from O'Reilly). The proper way to do that in make is:
> java_source_files = $(wildcard $(addsuffix /*.java,$(source_dirs)))
> java_class_files = $(patsubst %.java,%.class,$(java_source_files))
> compile_all: $(java_class_files)
> %.class: %.java
> $(JAVAC) $<
> I'm sure someone can find an example of when the command length is an
> actuall problem, but generally, it means that you're doing it wrong.
> You're trying to write your makefile like a scripting language,
> defining functions for doing tasks. Make is about defining
> relationships between files.
> ~ Luke Shumaker
> Bug-make mailing list
You could help some brave and decent people to have access to
uncensored news by making a donation at:
--- End Message ---