Support code structure (was RE: [Slightly OT] Source code management)

Lex Spoon lex at cc.gatech.edu
Thu Feb 7 13:39:08 UTC 2002




> BTW, another (though minor) point to make here is that on some platforms
> the relevant support libraries might already be installed. If I'm not
> mistaken then every Linux has a libjpeg.so so we'd just need to link
> against it rather than having to include the entire library per se. The
> above approach allows for this in a rather favourable way (e.g., ln-s
> the import library for weak linking instead of actually building the
> lib).

A few things on libraries.

First, I agree that it would be nice if libjpeg was in a subdirectory
the way libmpeg is, but that's just to make the directory tree cleaner. 
I don't see a big deal with it being in plugins/JpegBlahBlah as opposed
to somewhere else.

Second, it really is questionable to use older versions of a library. 
Normally having everyone use the same version is good software karma. 
With libmpeg, I might make an exception, because all versions of it seem
pretty yucky and maybe, soon, we won't be using it so much.

Third, nobody forces you to use the libmpeg just because it's available
on CVS.  But it's very nice to have it there.  And also, it's not
completely clear that using the pre-installed one is better -- there are
significant advantages to using the version the rest of the Squeak group
is using.


Finally, we really need to have releases in addition to CVS.  There will
be intermediate stages where one platform or another doesn't build, but
the releases should build.  And you don't have to use the most current
files to build a release, if something truly problematic comes up.




> I've stated this point over and over and over again and part of my
> reluctance to do anything at all at source forge is that the risk of me
> just screwing up yours or Lex's or John's latest work is just way to
> large to be ignored. I've screwed up before and I am _not_ an
> experienced SF user and I _do_ and _will_ make more mistakes.

It's an annoying possibility, but the version tracking means it isn't a
big deal, just like on Swikis.  If something gets messed up, then it's
very easy to fix.  And you'll know someone else has touched the code,
because when you do "cvs update" the file will be flagged.

The only thing I would mind about the shared code base is if two people
get in a commit war and *actively* start undoing each others' changes
repeatedly, but that doesn't seem to be what you're talking about.


> If I'm not mistaken then it _should_ be
> possible to say "get me all the sources from the canonical directory
> plus the hacks from X, Y, and Z" and have X, Y, and Z be completely
> different server.

That would be sweet!  (Though, too many X, Y, and Z's would probably
lead to a mess!)


On a lighter note:


Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> "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.
[snip]
> 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?


What I do is load all the files I'm using and then use "C-x b" to swap
from file to file.  There aren't any name clashes between different
directories.

This uses more memory than is required, but that just reminds me of the
old joke that Emacs stands for "Eight Megs and Continuously Swapping". 
While this is *exactly*, to the meg, the reason I didn't use Emacs when
I first learned Unix, it looks kind of funny now that people tend to
have 10+ times more memory than this.



-Lex



More information about the Squeak-dev mailing list