Re: multiple categories

[Guido Draheim]

Peter Simons schrieb:
> Guido Draheim writes:
>
>  > [btw, next time I answer ape man style... :-)=)]
>
> That's OK with me. :-)
>
> But maybe you misunderstand the reason why I keep asking the same
> questions repeatedly. It's not because I don't understand your reply
> linguistically, it is because I have the feeling that your answer does
> simply not address the question. Just looking at this very e-mail I am
> replying to ...
>
> I asked (note the emphasis):
>
>  >> Do we NEED to put a macro into more than one category?
>
> To which you reply:
>
>  > (a) there is no need to use it, it's optional
>  > (b) it is there when someone thinks it is good, and can use it.
>
> You say, basically: "If we have it, we can use it if we want to." But
> that is not d'accord with the facts, which are:
>
>  - The current infrastructure does not allow putting a macro into
>    multiple categories.
>
>  - The legacy input format does not allow putting a macro into
>    multiple categories.
>
>  - The XML input format does not allow putting a macro into multiple
>    categories.
>
> Thus, the "if we have it ..." is wrong: We do not.
>
> Thus, according to elementary logic, the "... we can use it if we want
> to" is irrelevant, because the premises is wrong already.

he he :-)=) that's why I warned about doing ape man style:

Your tool chain does not have it, I have hacked that into my
tools in a short time, and the sfnet visualization does now
use it. So - if I can do it then why can't you? :-)=)

> Furthermore, it does not answer the question I asked, which is:
>
>     Do we _NEED_ it?
>
> If there is one lesson I have learned in over 10 years of software and
> system design, it is: Don't add a feature unless you need it. Don't
> make systems more complex than they need to be. A system is not
> perfect, when there is nothing left to add, but when there is nothing
> left to take away.
>
> Adding this feature into the archive's infrastructure will require
> me/us ...
>
>  - to modify the software that generates the archive,
yes.
>  - to modify the legacy file format (and its parser),
yes.
>  - to modify the XML file format (and its parser), and
yes.
>  - to re-asses ALL macros now and EVERY TIME a new category is added.
yes.
> If that is not "adding complexity" I don't know what is.

how much? I've done it, and it didn't be hours and hours,
so this is not complicated but just a few hours of
work at a maximum. It is called `adding a feature` and
such takes some time and when that is done then it is
done. I have it (!) and... do you think your are incapable
to do a similar thing for its `overall complexity`? (again,
asking ape man style :-)=)..)

> Furthermore, the addition of this feature ...
>
>  - makes the submission formats easier to screw up for the submitter,
yes.
>  - thus increases the workload on the maintainers, and
neglible.
>  - makes the list of macros displayed per category longer.
slightly, less 10% usually.
> Finally, let me say that ...
>
>  - the original Autoconf package does not do it either.
what?
it packages multiple macros into a single file - it does
not split it up (each macro in a single file) nor does it
put all them in a single file. Well, that's what could
be called split by category, doesn't it? :-)=)

> So we have a _vast_ _array_ of disadvantages, whereas on the "gain
> side", we have ...
>
>  + it might make it easier for the user to find the macro.
>
> Which, I replied, would probably be an effect we would get at almost
> _no_ _additional_ _cost_ by adding a search engine to the web site,
> and probably more so.
again, I do not argue againt a search engine, but that is not the
same as a `browsable` visualization (using the mouse to look around).

> You also remarked that it would be nice to have for experimental
> macros, to which I replied: Can't we just put them into the
> "Candidate" category until they're ready for the submission procedure?

that's a difference between the gnu and sfnet part - I do split
experimentals by user. That's why I did not want to have that
one to be counted as an argument. Answering your question, yes,
there is not much of a difference, just a matter of taste, and
that taste can only be shifted when we have both and we can look
at both and see what `feels` better. I do not think such can be
handled by text and wordy abstractions...

> Please believe me that I am perfectly willing to add this and to
> support this feature, but please give me a good reason for doing so
> except for "it can't be difficult, so let's do it":
>
>  > (c) I had not problem implanting it, so I guess it is not "complex".
>
>
> On the topic of putting the m4sources into per-category subdirectories
> rather than all-in-one:
>
>  >> _Why_ is it not a good idea to put all the macros in one
>  >> directory?
>
>  > experience.
>
> Well ... :-)
>
>
>  > [It makes] no difference [for tools], where it is a difference to
>  > humans.
>
> > From my understanding, we have gathered the following points so far,
> '+' denoting "subdirectory approach", '-' denoting "all-in-one":
>
>  + Humans like it better than way.
>
>  - The "aclocal" tool doesn't cope with it.
>
>  - Paths change when a macro's category changes.
>
> > From my understanding, we are talking exclusively about the way the
> macros are installed on the system by the release archive, and in this
> case, I think that the human preference for smaller, more manageable
> portions of information does not outweigh the massively important
> points in favor of all-in-one. Humans can use the HTML document set to
> browse through the complete contents, sorted by category, "aclocal"
> cannot. (In fact, I think "aclocal" not supporting it is a killer
> argument in this case.)

*sigh* the `acinclude` tool does handle it - it is derived from `aclocal`
and as for the share/aclocal directy: it scans the subdirectories of
that, in othe words, it looks for share/aclocal/*/*.m4 instead of the
old share/aclocal/* thing.

It did turn out to be much more manageable that way, to have them all
in subdirectories - with putting all macros into the directory of
share/aclocal makes for some bad effects, ye know.
- people will want to pick up this feature for their own macros that
  they want to share across projects and people - that is similar to
  the package installed macros like `guile.m4` or `gtk-2.0.m4` or
  `sdl.m4`. However, here each one installs a single macro file
  which contains multiple macros (a category file!), and does not
  use the many-small-files approach of the ac-archive. That makes
  for a management difference, since you can not just use symlinks
  to the master m4 file in your changemanagment repository.
- carrying multiple macros across different sites and installations,
  (or using multiple version of autotools on one site) does exhibit
  the problem of a different nature: leftover macros. It happens
  that some of the time you create a macro, use it in some places,
  and rename/replace/delete it afterwards, or bind it up into some
  package m4 file. It happens that it will be properly deleted in
  one installation but not the other, simply for being forgotten.
  With subdirectories that is much easier to maintain
- and it also allows to bind macro sets from different places,
  not only the ac-archive but also user macros from the local
  site. Each user can have its own area to put up and kill away
  experimentals (possibly even using a single symlink to a
  directory in their home or personal changemanagement workspace).
  In this case, the category=directory names carry the meaning
  of where it does come from and how it is maintained.
- and last not least - yes, paths will change when the primary
  category changes. That's intentional and it can reflect
  difference to how it is maintained. The `ac-archive` central
  managemant is just an option, nothing more.

hth, cheers, guido