[m-rev.] for review: always-in-cur-dir group of extensions

[Peter Wang]

On Fri, 11 Aug 2023 13:16:06 +1000 Julien Fischer <jfischer at opturion.com> wrote:
> 
> Hi Zoltan,
> 
> On Thu, 10 Aug 2023, Zoltan Somogyi wrote:
> 
> >
> > On 2023-08-09 00:50 +02:00 CEST, "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> >> I have earlier mentioned the idea of grouping extensions
> >> by the algorithm we use to decide in which directory
> >> their files ought to end up in. This diff implements this idea
> >> for one group of extensions. If no-one objects to either the idea
> >> or to the naming scheme that this diff adopts, then I will
> >> apply the idea to the rest of the groups, Eventually I intend
> >> to then factor out the decide-what-directory-to-put-stuff-in code
> >> wherever that is possible. But before that is done, we should
> >> consider what extensions should have their treatment modified.
> >> I will post proposals for that in the next few days.
> 
...
> > Proposal D
> > 
> > At the moment, we put some kinds of library files into subdirs named "lib",
> > but we put .a files into "as", .dll files into "dlls", .init files
> > into "inits", and .jar files into "jar". I expect we want to keep
> > .dll and .jar files where they are,
> 
> Do we? I can't think of a reason for doing so. (Peter, can you?)
> 

No, I can't think of a reason.

> > Proposal F
> > 
> > We should reconsider the scheme for naming the subdirectories for extensions
> > that end in "s", which does happen. Specifically, we should add a vowel.
> > This would mean putting e.g. .class files in to subdirs named "classes",
> > not "classs". We could replace "analysiss" with "analyses"; I don't know
> > what we should do with "track_flagss"; all the alternatives I can think of
> > sound like hobbits :-(.
> 
> Apparently, the collective noun for flags is bunting, but I don't think
> track_bunting is an improvement ;-)  Is there any reason track_flags files
> could not be placed in a directory also named track_flags?

Or rename .track_flags files to something else. Or just leave things as
they are, as it doesn't matter.

I'm not sure why it was decided to separate files in the Mercury
subdirectory in the first place. (I can imagine some possible technical
reasons for doing so, but I suspect it was motivated by aesthetics.)

Nor is it clear why it was necessary to add the "s" suffixes on the
subdir names. But it is what it is, I'm not suggesting to change
anything.

I agree with Julien on each of the proposals.

Peter