Tim,

Tim Rowledge wrote:
> 
> It doesn't matter all that much to me what the underlying structure is,
> so long as fetching a module gives everything in the right place (duh).

That's exactly the problem and I'm thinking about it. And I want to
motivate others to think *with* me.

> Do remember that many platforms will not actually want all the plugins
> and so the module-stuff needs to reflect that

I know.

> - I had to delete the
> joystick/midi/soundcodec/profile and system external modules directories
> last night in order to get the event-vm to build, since there were no
> compilable files in them (make had some feeble complaint about no rule
> to make *.o or somesuch).

Did you make
	cvs update -P -d
(to prune) and
	make clean; touch configure.in; make
before?
Command
	touch configure.in
just to be at the safe side, it shouldn't be necessary to repeat it
often. But there is one trap: If you update, it's probable that your
specific configure files will be updated with the standard ones from SF.

I don't like these cryptic configure/make -files, but I have done (and
tested) my best!


> It seems like it would be nice if the sqcvs stuff could be used to help
> with this;

Of course. But it seems to be not in a ready to use status.

> if the generation methods could build the appropriate
> directory structure for the combination of internal/external modules you
> choose (and remember there is an opportunity for someone to make a nice
> little tool to help with that)

The
	[ENH][VM][2.8][2.9alpha?] VMModuleTranslation
posting was a first effort to address some of the dir and
sourcesBelongingTogether generation problems. Have you taken a look onto
it?
	*** There is existing code! ***

I don't like, if nobody looks into existing code (I have advertised it),
but all are making suggestion of making steps into an already chosen
direction...

What do you like and what not in the
	VMModuleTranslation
changeset? Feedback or improvements here would directly help the further
development!


Next goal is to get the platform specific Unix files back from the image
into SF, because

	*** I have accepted your critics regarding this point ***

, and getting them by Squeak from a local dir tree or - later! - SF
directly. But the introduced logic (look into VMModuleTranslation) seems
to be usable for me. At least nobody has critisized it so far!


> then there must be some way that the
> sqcvs systm could fetch the platform specific code and work out where to
> put it from the same information.

This is possible and nice and the *next* step. Many things *would* be
nice, but where are the implementors?

We *first* have to have a good directory structure at SF with *working*
make/configure -files!
This is my *actual* problem; and I don't like *this* problem. There are
other much more interesting things to do (e.g. realizing real
BlockClosures ;-) ).

So why I'm motivated here? Because I think a good SF and corresponding
Squeak infrastructure has a catalysatory effect of easing VM development
for all.

But in spite of these future sweets:
	I would be very happy if there would be other people hacking these
files, too! It's not my dream to do this...


> Remember that there is no difference
> in the platform specific code whether it is for internal or external
> usage - at least, there shouldn't be!

I know.

Greetings,

Stephan

> 
> tim

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