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

[Julien Fischer]

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 A
> 
> We should move the .exe extension from the "cur" group to the "cur_gs"
> group, which would mean that .exe files get put into a grade-dependent
> subdif if --use-grade-subdirs is enabled, and then *linked or copied*
> to the current directory, like all other executables.

Agreed. I suspect the current difference in their handling was never
intentional, just due to insufficient testing / usage on Windows.

> Proposal B
> 
> At the moment, we put most kinds of executable files into subdirs named "bin",
> but we put .bat files into "bats". Is this a windows tradition, similar
> to putting executables into "bin" for Unix/Linux?

No, it's not a Windows tradition.

> If not. then we should put .bat files into "bin" as well. And if want move
> .exe to "cur_gs", we should follow the same logic for it: put it either into
> "bin", or into "exes".

All executables should go in bin.

> Proposal C
> 
> We should move the .lib and .so extensions from the "cur" group to the "cur_gs"
> group, which would mean that .exe files get put into a grade-dependent

I don't think you mean .exe there.

> subdif if --use-grade-subdirs is enabled, and then *linked or copied*
> to the current directory, like all other libraries.

Agreed.

> 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?)

> but we should move .a files into "lib",
> and (depending on proposal C) we should do the same for .lib and .so as well.

Agreed. (And in the absence of a strong reason for not putting .jars and .dlls
there as well, we should move them there.)

> I don't have a sttong opinion on .init.

I would leave .init files where they are.

> Proposal E
> 
> We should change the status of the .defn_extents, .defn_line_counts, .defns,
> .imports_graph, .local_call_tree and .local_call_tree_order extensions.
> We should either move them from the "cur_ngs" group to the "cur" group,
> which would mean that they always get put in the current directory, or
> we should put them all into the *same* subdirectory with --use-subdirs,
> (Files with these extensions are designed to be looked at, acted upon,
> amd then deleted. They are mot expected to hang around long term, and
> storing the files of each extension in *different* subdirs leads to a
> proliferation of (most-of-the-time-empty) directories, which is also clutter.)
> 
> Note that some extensions with similar properties, such as .dependency_graph
> and .order, are already in the "cur" group.

Agreed.

> 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?

Julien.