Re: Target specific variables

[Jens Schweikhardt]

...
#   js> I realize there's the problem of "What's the delimiter between
#   js> diffenent variable assignments" (comma in my example). But maybe
#   js> I've overseen something. If not, Paul may treat this mail as a
#   js> feature-request :-)
# 
# Well, you've obviously hit on the most devastating problem.  The
# right-hand side of a variable assignment has no illegal characters.
# 
# The only possible solution would be (and this does _not_ work now so
# don't even bother trying it) using define, like this:
# 
#   define SET_SOME_VARS
#     CFLAGS = -DMUMBLE
#     LDFLAGS = -DFROB
#     YFLAGS = bar baz
#   enddef
# 
#   foo Foo: $(SET_SOME_VARS)
# 
# Since define preserves newline characters this could possibly be made to
# work.  It would be very difficult, though; the code is not structured in
# a way to make this easy at all.

I brainstormed a bit about the problem of delimiters. Here's a first
result.

- Even with the current state of affairs we are faced with an ambiguity:

  foo: CFLAGS = -DMUMBLE

  as a target specific variable assignment is indistinguishable from
  target foo having 3 prerequisites named CFLAGS, =, and -DMUMBLE.
  Indeed, older versions of gmake complain about "don't know how to
  make target CFLAGS".
  Recent gmake probably looks at the dependencies and if it looks like a
  target specific variable assignment it is treated accordingly.

- True dependencies are files or directories (or PHONY targets).
  represented by their name in the file system.

- If we have a way to write something that does not look like
  a file or directory we have avoided ambiguity.

- The only character that can't appear in absolute file names
  is ASCII NUL, ugh, so that's of no use.

- Empty path components (/foo//bar) rarely appear and when they do,
  it's more likely a bug than intended. In particular, // is a valid name
  in the file system (denoting the root directory) but its use as a
  dependency and written // instead of / is unheard of (at least for me :-)
  and extremely unlikely.

With that in mind, let's think about using // as some sort of special
token. It could mean: "When // appears as the next word after the
colon, the following nonblank character denotes a delimiter for multiple
target specific variable assignments." This should disambiguate

        foo: //, CFLAGS = -DMUMBLE, LDFLAGS = -DFROB, YFLAGS = bar baz

We can even resolve the currently existing ambiguity mentioned above:
// not followed by a nonblank means "This is a target specific
variable assignment, not a list of actual dependencies."

        foo: // CFLAGS = -DMUMBLE

We will confuse some poor C++ programmers I reckon :-)

Two hacks (for lack of a better term) I can think of is mentioning
the delimiter explicitly in a special target (similar to .SUFFIXES):

        .TARGET_SPECIFIC_VARIABLE_DELIMITER: ,     # name too long
        foo: CFLAGS = -DMUMBLE, LDFLAGS = -DFROB, YFLAGS = bar baz

Or by assigning MAKEDELIMITER=, similar to MAKEFLAGS.

Both hacks don't solve the currently existing ambiguity mentioned above.

Comments or suggestions welcome!

Regards,

        Jens
-- 
Jens Schweikhardt  http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)