Re: multiple categories

[Guido Draheim]

Peter Simons schrieb:
> Guido Draheim writes:
>
>  > [macros in more than one category]
>
> I'm sorry, but I honestly don't see your point. You say:
>
>  > I do think that pretty soon the autoconf macro archive will be
>  > filled with lots and lots of specific macros. [...]
>
>  > Therefore, I do expect that people will look into just one or
>  > two category areas [...].
>
>  > Therefore, to make it easier to find a good macro, it would be good
>  > to see it reference it all categories that the archive maintainers
>  > thinks it is good and would be right on topic.
>
> The "therefore" suggests that one argument logically implies the next,
> but I cannot make that connection. Putting a macro into multiple
> categories will make the archive _more_ ambiguous, not less. 
>
> I feel that what you're trying to achieve -- making it easier to find
> a macro in the archive -- is not served by this measure. IMHO, the way
> to go would be to add a search engine. You're looking for a macro that
> tests the types of the socket(2) call arguments? Look for "socket".
> Wondering whether the type foo_t is available in the system headers?
> Search for foo_t ... That is much simpler.

I do not argue against a search engine - in fact, I would like to see
a search engine, and furthermore...

> Furthermore, this is also an argument _against_ splitting up the macro
> index into several pages. In the current archive, you can use your
> browsers' "find" function to search to _all_ macro names, whereas
> splitting them into multiple pages will prevent that.

... furthermore an (long) index-list of possible keywords that is
derived / checked-back with the documentation of the macros.

As for the argument of having all macros on a single page, then
let me say (a) the macro name does not carry all, and the macro
names have lots of recurring bits that make the table very long
in kilobytes and (b) let a "find" better work on an index-list
that does just the possible keys to search for, pre-ordered in
fact to navigate quickly to it, and with an inverted-index of
possible matches in the macros. And finally (c) the frontpage
of sfnet has gotten too long to my taste, which influenced
the wish to break it into smaller pieces. I do expect the same
thing to happen with the gnu ac-archive in the near future.
Since it is not the case _now_, it makes you not have that
wish..... yet.

> Can you give us/me an example of a macro that should go into more than
> one category, given the category system we're planning to implement
> now?

stdint.h - c support, system headers
java home - installed package, java support
cc_for_build - cross compilation, build tool

The actual break-up of the macro series is somewhat free and it
makes for a limited number of dual cases.

this is independent of my own wish to have `recently obsoleted`
macros to still be around on topic pages somewhere near the
end of the table, plus the sfnet specific thing of experimental
and user macros (`under development`), to be also up there.

>  >> Using a more fine-grained category system would [make a large
>  >> archive user friendlier].
>
>  > but we do not have that much categories, and probably do not _want_
>  > to have too many anyway since it is best to make the whole
>  > ac-archive "browsable" [...].
>
> Why don't we want to have more categories than planned right now? 
>
> Why would having more categories make the archive less browse-able
> instead of more?

The number of categories should largely be dependent on the
global sum of macros - the more the ac-archive grows the
more should be added. It is not good to have too many
categories being `almost empty` which makes it uneasy to
browse through, and at the same time it uneasy to browse
through a long list filled with too many irrelevant entries.

let's say, as a rule of thumb, a category should have atleast
three entries and a maxium of slightly more than two screen pages.
If it grows beyond, split it up.

>  >> [obsolete macros should not appear in their old category]
>
>  > Say that someone says "pick up macro xx from ac-archive's c
>  > support", how does that turn out? Same thing for links into the
>  > ac-archive from somewhere else - the macro should persist for some
>  > time in its original place.
>
> If you look at the on-line archive, you'll find that all available
> macros follow this scheme:
>
>     http://www.gnu.org/software/ac-archive/htmldoc/MACRO_NAME.html
>     http://www.gnu.org/software/ac-archive/m4source/MACRO_NAME.m4
>
> The path of the macro does not depend on the category it is in. By
> changing a macro's category (ie- to "obsolete"), we do not change it's
> URL on the server.

That's good for the online archive. The sfnet branch is shipping
an `acinclude` copy of all the m4 macros, and it is not a good
idea to put them all into _one_ directory (Even the core autoconf
system does not put all macros into one file even if that is
possible). In a system copy, the main-categories are not just
virtual but physical, and obsoletion should not move it out of
the way (it re-orders, re-ranks it). That's what makes me prefer
to have the online-path to follow the path of the aclocal-copy.

-- cheers, guido