Re: [Doxygen-users] Doyxgen 1.2.7: \ingroup group1 group2 still allowed?

[Dimitri v. H. <di...@st...>]

On Fri, May 04, 2001 at 03:12:54PM +0200, Patrick Ohly wrote:
> Hi all!
> 
> According to the documentation (and implementation) of
> \ingroup an entity may be put into several different
> groups at once.

Yes, but...

> 
> However, later on in groupdef.cpp:addMemberToGroups()
> this is detected and triggers a warning (groupdef.cpp, line 617):
> 
>   Member ... found in multiple groups.!
>   The member will be put in group ..., and not group ...
> 
> The class MemberDef also allows to set only one GroupDef: 
>     setGroupDef(GroupDef *gd)        { group=gd; }

... members are an exception. Anything else can be in multiple groups.

> Are \ingroup and related mechanisms with more than one
> group per entity deprecated? 

No, but for members there is a slight problem.
Currently, a member is identified by its container and a local label
unique within the container (in html: a file and an anchor). 

Now suppose a member is in two groups and we want to (auto)link to it.
Where should the link go to?

A clean solution would be to link to the natural container of the
member (i.e. for a global function link to the file, for a class
member link to the class), regardless of any artifical group the 
member was put in.

But then what if someone wants its documentation to consist just of
the items that he/she grouped by hand? This would lead to ambigious
links targets in case the member is in multiple groups.

> If you ask me, then I'd be more than happy when each
> entity can only be in one group and I'd volunteer to
> clean up the implementation: 
> 
> - Entry::groups doesn't have to be a list.

It still does for entries that do not represent members.

> - An explicit \ingroup overrides an implicit @{ @}.

That would make sense.

> - A \defgroup @{ @} in one place overrides an \addtogroup @{ @}
>   in another place (e.g. header files uses \defgroup, C files use
>   \addtogroup) - this is currently impossible to implement, but
>   something that I have been missing for quite a while.

Well if it is impossible to implement, then feel free to try
the impossible :-)

Regards,
  Dimitri