"Garrett D'Amore" <gdamore at sun.com> wrote:
> Darren J Moffat wrote:
> > Personally I don't have any issue with /usr/include/schily/ it is no
> > better or worse than many of the other /usr/include/ subdirs that have
> > appeared recently.
> >
> > How is /usr/include/schily/ any different to /usr/include/ast ?
/usr/include/schily/ has a similar approach as /usr/include/ast
Both include a large set of include files that intend to create a platform
independent base for portable software.
> > From an architectural view point they look identical to me. They are
> > both subdirs in /usr/include that cover an integrated suite of "things".
What "GNU software" does is basically to follow the documentation for
"autoconf". This is: "take this code fragment and copy it into your source".
What /usr/include/schily/ and /usr/include/ast do is to put the portability
code _once_ into a central location instead.
> > To those that objected what exactly is the issue with
> > /usr/include/schily ? Is it because it is a derivative of Joerg's
> > name? If it is why is that a problem yet /usr/include/ast isn't ?
I see no difference in naming. If there was something similar as a portability
helper provided by the FSF, then it would doubtlessly be in a directory
/usr/include/gnu/.
> Three objections:
>
> 1) this is a single header -- creating a directory for a single header
> seems silly to me.
/usr/include/schily/ has more than 50 include files. None of them is usable
without the rest of the files. All files e.g. include <schily/mconfig.h>.
The file /usr/include/schily/librmt.h pulls in 9 other include files from
the /usr/include/schily/ tree:
/usr/include/schily/mconfig.h
/usr/include/schily/archdefs.h
/usr/include/schily/xconfig.h
/usr/include/schily/i386-sunos5-cc/xconfig.h
/usr/include/schily/prototyp.h
/usr/include/schily/types.h
/usr/include/schily/rmtio.h
/usr/include/schily/utypes.h
/usr/include/schily/param.h
> 2) "schily" as a directory seems "weird" to me. It references Joerg,
> but unless you knew to look for it, why would you look there. (I'm not
> entirely certain about ast either, but at least there is libast, so
> there is symmetry in that case.)
See above, it is not weird. Also note that the name of the directory has been
discussed in Autunm 2006 when the schily portability helper include files
have been moved into a subdiretory for better coexience with e.g. OpenSolaris.
There was no objection at that time.
> 3) I still have not got an answer as to why we even need to ship this
> header at all -- are we publishing a public API as part of this case?
> If so, then I think I want to see a bit more discussion about the API
> itself. If not, then just don't deliver the header, and the concern
> goes away.
Try to explain why there is /usr/include/ast/, maybe this helps you to
understand the "problem".
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
