Limited autoimport with globs in .import and .importzp

[pinobatch]

In my ca65 project, I have one .s file that defines sprite sheets and exports their IDs as symbols of the form SHEET_Hero, SHEET_Fungoid, SHEET_TurtleSoldier, SHEET_Lift, etc. (Names are changed.) I'd like to be able to refer to these sprite sheets in other files, setting up autoimport only for undefined symbols with a particular prefix:

.importzp SHEET_*

This feature request is inspired by Python's import statement and Java's import statement, both of which support * as a wildcard.

[cacciatc]

I bookmarked this issue a while ago as something I would like as well and finally this past weekend I gave it a try. Code at https://github.com/cacciatc/cc65/tree/limited-autoimport-with-globs. Note, it's a WIP, but it has been working with my preliminary tests and I am now using the globbed import's on my own NES project with no issues so far. Let me know what you think.

Implementation Notes

1. Both .import * .importzp * are not allowed since '*' is not a valid start of an identifier.

2. If globbed imports cover similar space, the last one will be matched (rather than the most permissive glob or the best matched glob); e.g.

; defined elsewhere
; .export mod1_var
; .export mod_var

.import mod*
.import mod1*

; picked up by .import mod1*
lda mod1_var

Most of the time the above wouldn't be a problem I think; however in the case of (3) there can be problems.

3. Be careful with similar imports across segments.

The following could cause a linker warning since the globbed import that picks up the symbol might not be the one you expect:

; defined elsewhere
; .exportzp mod1_var
; .export mod_var

.importzp mod1*
.import mod*

; picked up by .import mod*
lda mod1_var

Not sure if there is a way around the above behavior. The undefined symbol's address size when we get to SymCheckUndefined is the default, but maybe you can determine the required address size from the rest of the expr before then? Dunno enough at this time.

4. Glob imports create symbols which are ultimately unused and therefore omitted; however, you will see them in the sym table if you assemble with increased verbosity.

[pinobatch]

Could you get this fork updated to upstream/master? I've found some other people who might be interested.

[cacciatc]

Weird, I don't remember deleting that fork. Will see if I can track the code down on my local machine.

[cacciatc]

Found the code:
cacciatc@aefe204

Formatting may be a little messed up. Thought I had some tests as well, but couldn't find those...