It's ambiguous. There can be (and are) eggs that export procedures of the same name.
Procedures are exported from modules, not from eggs, right? Where's the
conflict?
Dependencies shouldn't get out of sync, and updated versions may change what is
exported... so I would question exactly what you are doing that would require
such functionality and whether there would be a better development methodology
that wouldn't shift the burden from paying attention to what one is using to a
psychic programme that does what you mean (not what you tell it).
Here it is:
https://github.com/scheme-requests-for-implementation/srfi-common/blob/master/srfi-tools/srfi-tools.egg
For practical purposes, that file is impossible to keep in sync even
though I wrote a tool to help.
I expect the best way to do it is manually list all the components of an
egg. Then give the "root" source file for each component, and it'd
automatically traverse starting from the roots.
AFAICT this is a good balance between automatic and manual - should give
quite predictable results. Library/module definitions have a known
grammar so you can find all the includes and imports.
The only complication I can see is cond-expand. Different cond-expand
clauses can have different imports/includes, so the code walker would
have to pin down the feature list.
That is quite a lot of stuff... You mention csm already, which does
most of this, but for packaging eggs I think this is a bit too much
automatic processing for my taste. I don't think such a feature belongs
into the core system, but a preprocessor (perhaps by scavenging code
from csm) or a mode for csm to emit egg files might be appropriate.
Fair enough.
If csm could generate .egg files I'd be happy with that. But csm's idea
is to work without any "makefile" or .egg style specification, right? So
it's even more automated than what I suggest.