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

 
 

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

sr #103149: namespaces for included files

Submitted by:  None
Submitted on:  Wed 23 Jun 2004 01:53:58 PM UTC  
Votes:  1  
 
Category: NonePriority: 5 - Normal
Severity: 2 - MinorStatus: None
Privacy: PublicAssigned to: None
Originator Email: -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>
Project 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

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 1 encouragement so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 19 Jun 2013 10:29:12 PM UTCnachumkCarbon-Copy-=>Added nachumk

    Back to the top


    Powered by Savane 3.1-cleanup