Is it true that all modules can equally well be compiled internally or
externally?  In fact, isn't it reasonable to compile modules *both* ways
in the same build?  If so, it seems odd to separate modules into
separate directories depending on whether they will be internal or
external.  So how about just:

	src
	CoreVM
	Modules
		BitBltPlugin
			BitBltPlugin.c
		SocketPlugin
			SocketPlugin.c
	ModuleSupport
		BitBltPlugin
			(empty)
		SocketPlugin
			sqUnixNetwork.c

Then, there can just be one config file listing modules to compile
internally, and another listing modules to compile externally.  It can
even be autogenerated for people who like that, and we can have happy
--thin and --fat flags.  Or we could *gasp* just have config files and a
make target which will regenerate them.  Certainly, though, it should be
allowed to compile a module both internally and externally.

Two more comments in general:

	1. Why is sqUnixNetwork.c linked into the image instead of into
SocketPlugin.so?  It seems odd that the auto-generated part is
pluggable, but not the fiddly platform-specific part.

	2. Instead of a single sqNamedPrims.h file, there should be a
namedPrims.inc file for each module that is auto-generated.  Then, the
makefile can generate a sqNamedPrims.h file which contains precisely the
list of symbols that will be included inline.  And on some platforms,
such a file might be useful for compiling external primitives, anyway.


As a final note, if make(1) gets annoying, we might think about
"jam"....
	
	http://www.perforce.com/jam/jam.html

I've never actually used it, but it sounds pretty nice.


-Lex



Stephan Rudlof <sr at evolgo.de> wrote:
> Dear VM'ers!
> 
> To ease the automatic generation of arbitrary combinations of internal
> and external plugins,
> I would like to change the structure from the current
> 
> Unix_2.8
> 	conf
> 	src
> 		CoreVM
> 		InternalModules
> 		  BitBltPlugin.c
> 		ExternalModules
> 			SocketPlugin
> 			  SocketPlugin.c   SocketPlugin.h   sqUnixNetwork.c
> 
> to the easier to realize evolutionary
> 
> Unix_2.8
> 	conf
> 	src
> 		CoreVM
> 		InternalModules
> 			BitBltPlugin
> 		  	  BitBltPlugin.c
> 		ExternalModules
> 			SocketPlugin
> 			  SocketPlugin.c   SocketPlugin.h
> 		SupportForModules
> 			SocketPlugin
> 			  sqUnixNetwork.c
> 
> or to the better IMHO
> 
> Unix_2.8
> 	conf
> 	src
> 		CoreVM
> 		Modules
> 			BitBltPlugin
> 				Internal
> 				  BitBltPlugin.c
> 			SocketPlugin
> 				External
> 			  	  SocketPlugin.c   SocketPlugin.h
> 				Support
> 				  sqUnixNetwork.c
> .
> 
> To the latter:
> - From Squeak there could be a direct removing/generation of the 
> Modules/*/Internal and  Modules/*/External substructures without
> affecting the Modules/*/Support part;
> - could serve as a basis for a good platform independent SF structure,
> just think of separating the .../Support part for every platform;
> - drawback: many makefile/config changes are necessary...
> 
> 
> What do you think about it?
> 
> 
> Note: This would make platform specific files in the image obsolete ;-)
> 
> Greetings,
> 
> Stephan
> -- 
> Stephan Rudlof (sr at evolgo.de)
>    "Genius doesn't work on an assembly line basis.
>     You can't simply say, 'Today I will be brilliant.'"
>     -- Kirk, "The Ultimate Computer", stardate 4731.3