Re: Partial automation of egg dependencies

[Lassi Kortela]

> 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.