Issue 70359 - remove forced shell calls (+ prefix)
Summary: remove forced shell calls (+ prefix)
Status: CLOSED FIXED
Alias: None
Product: Build Tools
Classification: Code
Component: solenv (show other issues)
Version: current
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: hjs
QA Contact: issues@tools
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-12 14:40 UTC by hjs
Modified: 2013-08-07 15:34 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description hjs 2006-10-12 14:40:33 UTC 
the only required foced shell call i'm currently aware of are those top address
4nt internal commands.
thus lots of useless shell calls are done for all platforms when executing commands.
Comment 1 hjs 2006-10-12 15:41:04 UTC 
hmm, hiding these in the shell specific tool variables (e.g. TOUCH) leads to
ugly constructs like

cd some_dir && $(TOUCH:s/+//) some_file

any idea?
Comment 2 quetschke 2006-10-12 16:48:23 UTC 
Yes, make '&' and '|' and '^' (for 4nt) SHELLMETAs. (Thet might be already)
Comment 3 hjs 2006-10-12 17:25:12 UTC 
the idea behind this was to define e.g.

TOUCH=+touch

for 4nt only and get rid of the "+" prefix for all other shells.

this leads to the problem in my previous comment.

extending SHELLMETAS doesn't help on single command use like

$(TOUCH) some_file
Comment 4 quetschke 2006-10-12 18:18:20 UTC 
Hmm, how about defining two touch macros, one for standalone recipes with the +

STOUCH=+touch

and one for composite recipes.

TOUCH=touch

Still ugly but no need for the s/+// anymore. And if someone uses the "wrong"
macro there will be a build error, easy to spot.
Comment 5 hjs 2007-01-17 15:06:54 UTC 
all gone in m199
Comment 6 rt 2007-01-24 10:34:10 UTC 
Code review for this issue really is no fun, but finally I've made it.
Verified on CWS ause069.
Comment 7 hjs 2007-01-30 14:27:55 UTC 
close this for now...
sure to need a second round to remove new ones. will do that in new issues