Balazs Scheidler <[EMAIL PROTECTED]> writes:
> Scripts and other tools are getting numerous in the source distribution,
> and there are over 200 (!) source files in the root directory. What about
> some kind of hierarchy, so we have the files organized a bit?
I don't think there is much point in arranging the files
hierarchically unless the hierarchy reflects some natural order the
files themselves. If a set of files are closely related, they should
be kept together.
> /doc - documentation, man pages etc.
This directory exists in cvs, but is almost empty. I think most of the
files (README, AUTHORS, TODO, ... belongs in the top-level directory.
Which files would you like to move to doc/ ?
> /src - source
Moving all source files into a subdirectory is an easy way to make the
top level directory cleaner.
> /lib - library files
What is your definition of "library" here? The lib/ and include/
directories exists, but are used only for the crypto code that can
easily be used and distributed separately (in fact, they are copied
from the crypto module for the pike interpreter,
http://pike.idonex.se). "lib" is definitely a poor name for this;
something more specific would be better.
> /include - library includes
In general, I prefer keeping "internal" include files together with
the corresponding source files. Using a separate include-directory is
best for files that are intended to be installed somewhere under
/usr/local/include, or something like that. Furthermore, some include
files have corresponding .h.x files. Where would you like to put them?
> /scripts - build scripts
Why? Note that if "build scripts" includes all special programs used
for automatically generating source files, that includes a few
C-programs as well (prime_table.c, desdata.c, digit_table.c). And
these programs interdepend on several other sourcefiles. I'm afraid
that the makefiles would get a lot more complicated if we spread
closely related files across several directories.
I'm not saying that I'm against moving files around, but I don't want
to do so without good reason.
> I have written a perl script for checking the range of pty devices a given
> distribution has. It inputs a header file, and expands a macro called
> PTY_BSD_DEFS to four defines:
>
> #define PTY_BSD_FIRST_MIN 'p'
> #define PTY_BSD_FIRST_MAX 's'
> #define PTY_BSD_SECND_MIN '0'
> #define PTY_BSD_SECND_MAX 'f'
Hmm. Perhaps it would be better to use strings rather than upper and
lower limits. Like
#define PTY_BSD_FIRST "pqrs"
#define PTY_BSD_SECOND "0123456789abcdef"
There are at least two problems with ranges:
� It is not clear what the range '0' - 'f' really means (there's an
implicit gap between '9' and 'a').
� One range may be insufficient for some systems. For instance, it
appears that, on this machine, the first character can be one of
"abcdepqrstuvwxyz" . Note the gap between 'e' and 'p'.
Something even more general would be to simply list all the devices,
char *pty_names[] = { "/dev/ptya0", ... };
#define NUMBER_OF_PTYS (sizeof(pty_names) / sizeof(pty_names[0]))
> It may be better to achieve the same using autoconf, but I don't know
> that beast too much. :-)
When considering requiring yet another tool for building, there are
two quite different cases.
We have the tools needed for installation (i.e. ./configure ; make).
Currently, the only requreed tool beyond a C compiler and the standard
unix commands needed for running the configure script is GNU-make. And
I would be happy if GNU-make could be deleted from this list.
And we have the tools needed to be able to hack the code. This list is
a longer: autoconf, GNU-make, gcc, bash, scsh, gperf, just to name a
few.
Adding perl to the second list is ok with me (even if I might prefer a
scsh script ;). Adding it to the first list is worse. I think a test
written for /bin/sh (which could be inserted directly into
configure.in) would be better. Or a test done entirely at run time.
/Niels
