[Omake] SVN Commit: OMake Build System (Rev. 9061)
Aleksey Nogin
nogin at cs.caltech.edu
Wed Apr 12 10:11:14 PDT 2006
On 11.04.2006 22:42, Jason Hickey wrote:
> I propose the following policy (1.5).
> - Array elements are glob-expanded.
> - Array elements are not expanded for other shell characters.
Corner case - will argv wrappers work? For example (from LaTeX.om):
Shell. +=
stdout-to-err(argv) =
stdout = $(stderr)
$(argv)
Or from mk/prlcomp in MetaPRL:
#
# XXX: JYH: this seems kind of inefficient to me.
# We should fix omake so that the final line can
# just be $(argv).
#
Shell. +=
prlcomp(argv) =
setenv(MP_ROOT, $(ROOT))
setenv(MPLIB, $(LIB))
setenv(MP_GROUP, $(THEORYNAME))
setenv(MP_DESCR, $(THEORYDESCR))
setenv(MP_INCLUDE, $(concat :, $(OCAMLINCLUDES)))
code = $(shell-code $(argv))
if $(eq $(code), 0)
return 1
else
exit $(code)
Note that the first element of argv should be allowed to be a Shell.
alias itself!
At the very least, the "call-argv" function such that the last line in
such wrappers can be
$(call-argv $(argv))
should be (easily?) definable.
I would guess that when passing the arguments to a Shell. function we could:
- Turn all the elements that were glob-expanded (or {}-expanded) into
ValData
- Leave all the other valued in argv as is
- Pack the thing into an array.
Would that make it work?
P.S. In my mind the issue is exactly that - while it is not too hard to
make a set of choices that seem reasonable at first, once we consider
all the corner cases and non-obvious usage scenarios, some of these
choices may end up having some very unexpected (or at least - very
unexpected to me) side-effects. It would be nice to have at least some
minimal level of confidence that the picture would stay reasonably
consistent once those corner cases and weird usages are taken into
account...
--
Aleksey Nogin
Home Page: http://nogin.org/
E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal)
Office: Moore 04, tel: (626) 395-2200
More information about the OMake-Devel
mailing list