On 11/28/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Hi Jerry,
>
> I'm just curious, I don't mean to criticize your ideas. Just, give
> some "why"s for the "should"s.
>
no worries--this isn't criticism, it's feedback.
> On 11/29/05, jerry gay <[EMAIL PROTECTED]> wrote:
> > the parrot directory structure is large and a bit disorganized.
> > let me give you some examples:
> > * build_tools/, util/, and tools/*/ each contain utility perl
> > scripts. these should be grouped together under tools/, which
> > already contains subdirectories
>
> Why must all perl scripts be grouped under one directory?
>
perhaps my language was too imprecise here. let me try to clarify.
there are multiple directories off the root that contain tools and
utilities (most, if not all of which, are written in perl.) some are
used during development, some during build, and some during test.
grouping these tools and utilities together will give parrot
developers (and users) greater ability to infer the purpose of the
files based on their directory locations.
it requires too much knowledge of parrot in order to know that
development tools belong under tools/dev/, testing tools like the
smoke server belong under utils/, and build tools can be found under
build_tools/. i believe moving these directories under one parent
(tools) would flatten the learning curve.
> > * there are multiple dirs containing C source code (charset,
> > classes, io, etc.) these should be grouped together under src/
>
> Why must all C files be grouped under one directory?
>
again, perhaps i was imprecise--it's not a breakdown by language type
i'm looking for. in fact, the files in ops/, dynclasses/ and classes/
aren't even C files -- C files are generated from them. but, they are
logically source files. keeping all source files under one parent
would increase clarity and flatten the learning curve by keeping like
things together.
> > * the editor/ directory contains files for text editors and has
> > a generated makefile. there is no reason for this to be a make
> > target. a perl script should be created to replace makefile,
> > and the dir moved with the other tool & utility scripts.
>
> Why can't we use make for this? Make handles modification times and
> rebuilds on demand based on dependencies. imc.vim (and a few others
> IIRC) are built from dependencies, and if the dependencies haven't
> been changed, they don't need to be rebuilt. That sounds like make's
> job to me.
>
perhaps you are right here. there is a makefile target ('tags') which
calls the editor makefile. i don't have or use ctags, so i forgot
there was even a target for making tags. the tags target is not run as
part of the default make target, so only if a developer calls 'make
tags' will the editor makefile run. the editor syntax files are
regenerated if any ops files change, so there is indeed a dependency
there.
however, the syntax files are not installed, even if 'make tags' is
run. you must 'cd editor && make vim-install' (or 'kate-install') if
you want to actually update your editor. so, really, i don't see the
purpose of having this as a make step, since it doesn't finish the job
(and shouldn't! make shouldn't just install things whereever it wants
to on your system without you telling it to, like typing 'make
install'.)
anyway, i'll leave decisions on removing the makefile from editor/ up
to chip and leo, but my feelings are that it doesn't belong as part of
the make cycle, and is better off as a seperate utility, like
regenerating the MANIFEST.SKIP file (also a seperate utility.)
thanks for the feedback. hopefully i have better conveyed the reasons
behind my proposal.
~jerry
