This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Flatten sysdeps/unix/bsd/bsd4.4 into sysdeps/unix/bsd
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Thomas Schwinge <thomas at codesourcery dot com>, <libc-alpha at sourceware dot org>
- Date: Tue, 11 Sep 2012 19:58:13 +0000
- Subject: Re: Flatten sysdeps/unix/bsd/bsd4.4 into sysdeps/unix/bsd
- References: <Pine.LNX.4.64.1205091700350.31572@digraph.polyomino.org.uk><878vgrqksm.fsf@schwinge.name> <Pine.LNX.4.64.1207082051570.6840@digraph.polyomino.org.uk><20120709074815.46B0A2C0A7@topped-with-meat.com><Pine.LNX.4.64.1207091519000.1849@digraph.polyomino.org.uk><20120709154254.DBD172C0B2@topped-with-meat.com> <878veayebx.fsf@schwinge.name><Pine.LNX.4.64.1207271341180.24556@digraph.polyomino.org.uk><20120727161342.CD4662C0E4@topped-with-meat.com><Pine.LNX.4.64.1207311412420.17766@digraph.polyomino.org.uk>
On Tue, 31 Jul 2012, Joseph S. Myers wrote:
> On Fri, 27 Jul 2012, Roland McGrath wrote:
>
> > As I said when I introduced Implies-after, I don't think we should have any
> > more uses of it. Instead, we should get to the real work of revamping the
> > sysdeps directory selection process thoroughly.
>
> As a practical matter of making incremental progress on simplifying the
> directory structure so it's easier to understand what the possibilities
> are for any revamp, it would seem better in that case to change how
> missing directories are handled so Thomas's patch isn't needed, or to
> leave a README behind in an otherwise empty bsd4.4 directory (or to leave
> some other file behind, but that seems worse).
>
> (Actually I think use of Implies-after is the better incremental state: if
> there are multiple use cases for orderings that can only now be achieved
> through Implies-after, it's much better for understanding the current
> state and the requirements for any new system that those use cases be
> directly visible through use of Implies-after than that they be
> implemented in a more obscure way because it was once thought that only
> one configuration had such a use case.)
Does anyone else wish to express views on this point I made in
<http://sourceware.org/ml/libc-alpha/2012-07/msg00635.html> - that it
seems preferable to make it explicit through Implies-after that the
Implies-after semantics are in fact required and used by Hurd, given that
they are, than by having those semantics implemented for Hurd in an
obscure and indirect way depending on the existence of an otherwise
unnecessary directory level?
--
Joseph S. Myers
joseph@codesourcery.com