Simon Josefsson <[EMAIL PROTECTED]> writes:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> Simon Josefsson wrote:
>>> > I propose to move these modules to modules/crypto/
>>>
>>> I've done that now.
>>
>> May I ask to put the 'memxor' module back to the top level? It is an
>> independently usefu
directory is /home/k/ka/karl
Two levels is a bit much, I agree.
has no benefit
Well, I think there is a small benefit to having smaller directories (in
whatever scheme) than one gigantic directory, even if it is nothing
beyond "subdirectories for the sake of subdirectories". Technically
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> > I propose to move these modules to modules/crypto/
>>
>> I've done that now.
>
> May I ask to put the 'memxor' module back to the top level? It is an
> independently useful utility. It can be used in implementations of
> Commo
Simon Josefsson wrote:
> > I propose to move these modules to modules/crypto/
>
> I've done that now.
May I ask to put the 'memxor' module back to the top level? It is an
independently useful utility. It can be used in implementations of
Common Lisp's bit-xor function, or in GF(2)^n vector arithm
Simon Josefsson <[EMAIL PROTECTED]> writes:
> I propose to move these modules to modules/crypto/
I've done that now. I'm not sure whether to also move the *.{c,h}
files to lib/crypto/, so I'll wait with that for a while.
/Simon
Karl Berry wrote:
> Actually, I suggested it because I thought it was better for humans (as
> well as computers).
I don't think it is. Have you ever worked on a machine where your home
directory is /home/k/ka/karl, and your project upload in
/home/ftp/t/te/texinfo? I hate it. I causes extra typing
James Youngman wrote:
> you've made me wonder if it's useful just to follow whatever
> directory organisation glibc uses...
Definitely not. In glibc you have subdirectories for families of architectures
(soft-fp), by functionality (crypt, intl), by standard (posix), and by platform
(hurd, mach). A
Paul Eggert wrote:
> Like others, I like the idea of grouping but I'm afraid the initial
> group proposal didn't sound that felicitous.
>
> > The expected benefit is that
> > 1) that people looking for a particular function and whether gnulib
> > support it can find it immediately, without
IMHO I don't think it is a good
separation from a human point of view.
Actually, I suggested it because I thought it was better for humans (as
well as computers). At least I know I personally would find it easier
to use than any other split proposed so far. With the alphabetical
scheme,
[EMAIL PROTECTED] (Karl Berry) writes:
> Not to be low-tech, but how about 26 subdirectories a..z?
> That way, if I know the name, I know the subdirectory.
That's a good solution to improve performance for computers (which
tend to dislike large directories) but IMHO I don't think it is a good
sep
Not to be low-tech, but how about 26 subdirectories a..z?
That way, if I know the name, I know the subdirectory.
On 3/29/07, Simon Josefsson <[EMAIL PROTECTED]> wrote:
That's true. I guess it depends on the refactor discriminator.
Either based or content (crypto, unicode, string-functions,
math-functions, etc), or type (header, file, etc). To me, all the
crypto stuff seems self-contained and uninteresting
Bruno Haible <[EMAIL PROTECTED]> writes:
Like others, I like the idea of grouping but I'm afraid the initial
group proposal didn't sound that felicitous.
> The expected benefit is that
> 1) that people looking for a particular function and whether gnulib
> support it can find it immediatel
Bruno Haible wrote:
> Simon Josefsson wrote:
>> Refactoring seems like a good thing. Your proposed two modules/
>> directory split didn't strike me as the obvious way to go, but I
>> haven't really thought about it.
>
> Yes, a categorization according to topic, like James proposes, was
> also my
Jim Meyering <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> wrote:
> ...
>> I'm Cc'ing Jim because he is the owner of the md5 module. I believe
>> md5 is the only crypto-related module that I'm not the owner of. Jim,
>> are you ok with moving the md5 module to modules/crypto/
Simon Josefsson <[EMAIL PROTECTED]> wrote:
...
> I'm Cc'ing Jim because he is the owner of the md5 module. I believe
> md5 is the only crypto-related module that I'm not the owner of. Jim,
> are you ok with moving the md5 module to modules/crypto/ together with
> the rest of the modules?
Hi Simo
Bruno Haible <[EMAIL PROTECTED]> writes:
>> I propose to move these modules to modules/crypto/
>
> Maybe it is wise to consider the dependency structure when creating this
> subdirectory? The 'md4' module is not dependent on the other crypto modules,
> and the other crypto modules don't depend on
Simon Josefsson wrote:
> Refactoring seems like a good thing. Your proposed two modules/
> directory split didn't strike me as the obvious way to go, but I
> haven't really thought about it.
Yes, a categorization according to topic, like James proposes, was
also my first thought. But some modules
James Youngman wrote:
> Perhaps something like this?
>
> posix - for implementing POSIX functionality on broken systems
> glibc - for gnulib's implementation of functions available on GNU
> systems but not posix (i.e. for things we should sometimes sync with
> glibc)
This will increase the lookup
Bruno Haible <[EMAIL PROTECTED]> writes:
> Objections?
Refactoring seems like a good thing. Your proposed two modules/
directory split didn't strike me as the obvious way to go, but I
haven't really thought about it.
Btw, a lot of modules would go away of I moved all crypto-related
stuff into a
On 3/29/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
gnulib now has more than 600 modules, some of which are already in
subdirectories. Still, there are more than 500 modules at the top level.
I propose two new subdirectories in the modules directory, with the aim of
clarity:
1) a subdirectory
gnulib now has more than 600 modules, some of which are already in
subdirectories. Still, there are more than 500 modules at the top level.
I propose two new subdirectories in the modules directory, with the aim of
clarity:
1) a subdirectory headers/
2) a subdirectory functions/
The headers/
22 matches
Mail list logo
