guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Module name == dir hierarchy seems to make devel awkward...


From: Martin Grabmueller
Subject: Re: Module name == dir hierarchy seems to make devel awkward...
Date: Fri, 23 Mar 2001 08:02:25 +0100

> From: Rob Browning <address@hidden>
> Date: 22 Mar 2001 17:14:43 -0600
> 
> With the current module system, it seems like in my development
> directory for guile-opengl, if I wanted to work without having to do a
> "make install" every time I made a change, I'd have to have a mostly
> empty deep subtree for all my files.  i.e. my project's directories
> would have to look something like this:
> 
>   guile-opengl/INSTALL
>   guile-opengl/README
>   guile-opengl/Makefile.am
>   ...
>   guile-opengl/graphical/3-d/fancy/opengl.scm
>   guile-opengl/graphical/3-d/fancy/opengl/low-level.scm
>   ...

This is exactly what pissed me off when writing Java code for my last
employer...  My tab key really suffered from repeatedly opening files
in different Java packages in Emacs...

> So I'd have three levels of empty subdirectories just to mirror the
> eventual install hierarchy.  To me this seems awkward, but I don't see
> an alternative given the current module system design.

This is not related to the module system, I think.  Only the part of
the module system implementation which constructs file names knows
about the module name => filename mapping.

> So is there an alternative, or is this just expected?

I can imagine an alternative, but I am not sure if it is a good one.
The module loader (which maps module names to file names), could
instead of:

  (graphical 3-d fancy opengl) => graphical/3-d/fancy/opengl.scm

do the following (or something equivalent, you get the idea):

  (graphical 3-d fancy opengl) => graphical-3-d-fancy/opengl.scm

Whether this is more maintainable, I am not sure.  It would be easy to
implement.

A more complicated solution would be to define additional name mapping
rules, maybe in a configuration file.  Personally, I dislike this,
because it complicates implementation, usage and maintainance without
helping much.

Regards,
  'martin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]