mainmake - Support: sr #103149, namespaces for included files

 
 

You are not allowed to post comments on this tracker with your current authentication level.

sr #103149: namespaces for included files

Submitter:  None
Submitted:  Wed 23 Jun 2004 01:53:58 PM UTC
Votes: 1
 
Category:  None Priority:  5 - Normal
Severity:  2 - Minor Status:  None
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  None

Tue 12 Sep 2006 11:05:42 AM UTC, comment #4: 

Thank you for the reply. I hadn't noticed it until now.

To answer the points you raised (or at least clarify my meaning):

> It seems obvious that you'd want this to print "local" not
> "global", but the evaluation of the variable happens in the
> context of the global scope.



Localizing all variables automatically would be nice, but I think that it is probably too far from the "way make works" to be imlpemented easily. And actually I was not so concerned about this as such. My main purpose was to stop trampling on the global BIZ and "peer" BIZ declarations. Given that, I think it would be acceptable for the evaluation to print "global". It would be nice to have a way to "localize" any reference of course, but I am pretty much ok with deferred evaluation remaining the way it is. So to expand your example:

BIZ = global
scope FOO {
BIZ = local
BAR = $(BIZ)
}
scope BAZ {
BIZ = local
BAR = ${localreference $(BIZ)}
}
scope BAM
{
BIZ := local
BAR := ${BIZ}
}
all: @echo foobar = ${FOO::BAR}, bazbar = ${BAZ::BAR}, bambar = ${BAM::BAR}

would echo the following
foobar = global, bazbar = local, bambar = local

Though obviously the notation for localizing a variable reference sould be nicer. Verbosity is just for illustration purposes while this feature doesn't exist :) I think the FOO::BIZ you use is not really ok, since the person then has to know the name (and probably degree of nestedness) of the current local scope.

> As far as scoping targets, that's an even MORE difficult issue.
> Variables can be scoped with some kind of naming convention, but
> targets are not like that. They represent files, typically, and
> files don't have any sort of "scope". I have a difficult time
> seeing how this could work for targets.


I must admit that mostly I was thinking of them as .PHONY targets, but I think that basically the "real target" would be the scopeless target name.

i.e.

scope FOO {
afile: echo "foo::afile" > $@
.PHONY: prepare_afile
prepare_afile: afile
}
afile: echo "afile" > $@

> make afile

echo "afile" > afile

> make FOO::afile

echo "foo::afile" > afile

> make FOO::prepare_afile

echo "foo::afile" > afile

Basically this allows someone to componentize the make more easily, as in the "a.mk, b.mk, c.mk" example in the original savannah request item. (well, more easily, ignoring the existance of recursive make)

That's not to say it would not be also  nice to have some optional way to manipulate the scoped targets to e.g. prepend a directory without rewriting every rule, but that is building a house on imaginary foundations, so I'll stop there.

Ian <ian_jd>
Wed 08 Feb 2006 05:26:44 PM UTC, comment #3: 

Something like this would require very careful thought, and the rules for evaluation would be complex.  Suppose we had something like:

  BIZ = global

  scope FOO {

  BIZ = local
  BAR = $(BIZ)

  }

  all: @echo $(FOO::BAR)

It seems obvious that you'd want this to print "local", not "global", but the evaluation of the variable happens in the context of the global scope.  We cannot go through recursive variable values and replace all variable references when BAR is defined, because make promises to not even glance at those contents until the variable is evaluated... we don't even know for sure that $(BIZ) is a make variable reference!  Depending on how BAR is used it might appear in a completely different context.

What this means is that this cannot be implemented 100% in the parser (unless we instantiate some fairly draconian rules, like all variable references must be fully-qualified with their scope even in their scope, like:

  scope FOO {

  BIZ = local
  BAR = $(FOO::BIZ)

  }
), and that variables must carry around a reference to their scope internally, which must be installed every time that variable is going to be expanded, etc.

As far as scoping targets, that's an even MORE difficult issue.  Variables can be scoped with some kind of naming convention, but targets are not like that.  They represent files, typically, and files don't have any sort of "scope".  I have a difficult time seeing how this could work for targets.

Paul D. Smith <psmith>
Group administrator
Tue 21 Sep 2004 02:57:35 AM UTC, comment #2: 

The solution in the comment (using .SCOPE, .ENDSCOPE) does not appear to actually work. It gives an error " * missing separator.  Stop." using make 3.80 or the CVS make.

Anonymous
Wed 21 Jul 2004 02:50:44 AM UTC, comment #1: 

.ALIAS TOPLEVEL_CFLAGS=CFLAGS  # keep a reference to this
# CFLAGS is still the top-level one
.SCOPE CFLAGS LDFLAGS
# now CFLAGS and LDFLAGS are local
FOO := foo    # FOO is not local
.ENDSCOPE
# now CFLAGS and LDFLAGS go back to being top-level
# while FOO remains modified

Anonymous
Wed 23 Jun 2004 01:53:58 PM UTC, original submission:  

Just an idea for the future:

It would be good to have the option to enable separate namespaces for included .mk files. And a way to address them of course. This would reduce the difficulty of creating compatable include files without worrying over messing up the variables of the parent. This is important when trying to do non recursive makes for large systems.

My suggestion is a  "import" keyword that is an alternative to "include", It would automatically put the imported file's variable, target, and defines (anything else?) into it's own namespace based on the imported file's pathname.

It would also use the same include search as the CPP's #include rather than make's include one.

# begin GNUMakefile
IMPORTS := a.mk b.mk c.mk
import ${IMPORTS}

default: ${patsubst %, %::default, ${IMPORTS}}
all: ${patsubst %, %::all, ${IMPORTS}}
clean: ${patsubst %, %::clean, ${IMPORTS}}
# etc...

# end GNUMakefile

and the .mk files can trash CFLAGS and any other variables or targets as much as they like, without worrying that they will break something in the "main project".

I know you probably prefer recursive invocations of make for this kind of thing though :-)

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nachumk (Voted in favor of this item)
  •  

    There is 1 vote so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-06-19 nachumk Carbon-Copy- Added nachumk

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code