"Andreas Raab" <Andreas.Raab at gmx.de> is claimed by the authorities to have written:


> My (more psychological) "problem" with this structure is that it doesn't
> go together at all with my working style.
[snip]
> It eats up my short-term memory chunks just to remember those
> directories (six of them so it's full ;-) whereas in my current
> structure I can just play "trial and error" (using Emacs and ensuring
> there's always at least one window on win32 and one on generated) and
> concentrate on solving the problem.
So it sounds to me like you _really_ need to use a decent tool that
can help you remember all this complication, yes? If you can't be
persuaded to use something less antediluvian than emacs (yes, yes, my
tongue is firmly in my cheek, and I have my fireproof underwear on
ready for the emacs fanclub) then I'm sure somebody expert in using it
(I was, once upon a time but I managed to give it up, to the
considerable benefit to my remaining sanity) should be able to offer
suggestions on more efficient navigation. I do have vague memories of
emacs being reasonably good at that.

Personally I usually just dump the entire fileset into my programming
editor, which makes for instantaneous all-texts searches for functions,
variables etc. Not to mention find-and-replaces. Maybe you should get an
old second hand Acorn?

Seriously, if your main practical problem is navigational, then lets see
if there is a way to help. Scott might suggest getting a memory upgrade
:-J

[snip]
> So let me bounce the question: What is wrong with the structure that Ian
> and I are using for years?!
There is no structure that can help one to work out any meaning to the
collection of files. Perhaps this doesn't bother you, or indeed anyone
but me.

In 'generated' you find all the files dumped from the image (not all of
which are generated of course, so it's a misleading name anyway) and
even then, only if you run the incantations and copy the files - since
the normal behaviour is to dump them in the current directory. In some
cases I've found that to be a decidedly non-intuitive location,
depending on the UI in use and how the image was started. One of the
small advantages of the VMMakerTool is that it shows you reasonably
clearly where the files will go and gives an opportunity to put them
somewhere else. Since all the files are smooshed together, there is of
course the potential for clashing filenames as well. This is something
you quite correctly pointed out yourself just a few weeks ago.

In 'unix' (since I happen to have a copy on my machine rather than a
copy of the windows equivalent) you find a moderately complex tree of
files, certainly not a million miles from the tree I used - not
surprising since I more or less copied the ideas. However, again there
is no separation of the files used for core vm, internal or external
plugins. I find that confusing and irritating, maybe you don't. De
gustibus non disputandum est (loosely translates as "anyone
that disagrees with me is clearly deluded").

To discriminate which files go where and what plugins are external, one
has to edit the file 'PLUGINS' which at one time had a quite definite
statement by Ian that he thought it was a dreadful thing to do - I
agree. By splitting things up we can write reasonably simple scripts
that can derive the right sets of files for each module, on those OSs
thatallow such scripting at least. For OSs where the task must remain
manual, the structure at least provides a decent clue to the makefile
manipulator. For new ports, the structure could even be said to provide
the beginnings of a guide to what must be implemented and what can
optionally be implemented.

I would point out that, if a structure is really not wanted, then
VMMaker could quite reasonably generate a more explicit configuration
text; in fact we have been discussing using it to generate at least
fragments of the makefile.



[snip]
> Another problem that I've mentioned before is the issue of copying files
> around (though one might say this is a VMMaker and not a structural
> problem). But you know all about that and I don't need to repeat this
> here.
VMMaker5 does not copy files around. Unless you specify that it should.
Oddly enough, you were a very vociferous exponent of not copying files
- which I have come to agree with - but having the files tree in one
place would solve (most of) your tool problems. The alternative of using
links might seem attractive?

> 
> > I recall that you
> > suggested that the jpeglib (and mpeglib?) libraries ought to be
> > separated out, which has merits of cleanliness but possibly 
> > complicates makefiles. 
> 
> Perhaps so but I think that the advantages outweigh the possible
> complications by far.
[snip]
I agree mostly. It does rather go against the concept of making the
downloading of a complete set of files easy though. If the library _is_
included anywhere in our tree, it runs the risk of being out of date; if
not, it has to be explained where to get it etc. 


>  you might just have a little local makefile that says "cd
> libjpeg; configure; make" and all will be well no matter what platform
> you're on.
Probably not unfortunately - at least Mac will probably have problems
with making it that simple.
[snip]

> > What other problems do we need to solve?
> 
> Most definitely that of diverging source code across platforms. E.g., I
> use an old version of libmpeg. The one at source forge doesn't work for
> Windows. But I don't see a reason in just not delivering an mpeg plugin
> if an older version of the library works well. How do we deal with this
> issue?!
> 
> You might say this is a CVS question, use tags, etc. but that is not
> true.
This is very dependant on the style of use considered. If the cvs usage
were generally to be "fetch me the files for a windows build" then
tagging etc would absolutely solve the problem since you would get
the files tagged for a windows build.
If the normal usage were "get me the entire world of Squeak vm files"
then it would be relatively simple to have a directory for libmpeg
suited to windows kept 'separately'. End of problem I think. Goran or
Rob can probably explain details of how (or even if) interesting tricks
can be used to avoid actually doing the naive thing and really keeping a
separate copy.

> In the worst case you could in fact have completely independent sources
> - and we do have those already. Notice the (somewhat ridiculous) #ifdef
> NO_STD_FILESUPPORT in the file primitives. I needed them in order to be
> able to override the "cross-platform" version of the file primitives.
With the current VMM tree you could simply keep a replacement version of
sqFilePluginBasicsPrims.c in the
platforms/Win32/plugins/FilePlugin windows branch. Then the
NO_STD_FILE_SUPPORT could be removed from the common copy. Come to that,
you don't even need to name it the same so long as your makefile does
the right thing.
 
tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Your password is pitifully obvious.