"James C. McPherson" <James.McPherson at Sun.COM> wrote:
> > The definitions in /usr/include/schily/ are not only used by star but by
> > many
> > other programs - some of these programs are already on Solaris. They are
> > needed
> > if you like to use interfaces from
> >
> > libschily, libxtermcap, libfind, libdeflt, libparanoia, librmt,
> > libscg/librscg
>
> I don't have any of those libraries installed on my SXCE build 83 system.
> They are not required for any currently integrated part of OpenSolaris.
Well, you already have programs on your SXCE build 83 system that have been
linked against these libraries.
> Other people have asked you why /usr/include/schily contains such
> files as param.h and utypes.h. Since we already ship the file
> /usr/include/sys/param.h, what benefit does having a private copy
> in /usr/include/schily serve?
You are a developer and I am sure that you understand the reason if you look
into these files. They are needed for the same reason as e.g.
/usr/include/ast/ast_limits.h
/usr/include/ast/ast_param.h
/usr/include/ast/ast_stdio.h
exist. The main difference is that programs using the "ast portability" do
#include <ast_param.h>
cc -c -I /usr/include/ast *.c
while programs based on the "schily portability" layer use:
#include <schily/param.h>
cc -c *.c
We already had a discussion with David Korn that both basic approaches are so
different because they are so simular ;-)
I believe that my approach is easier to understand and more obvious.
...
> Again, that is not actually the point.
>
> What is the point here is that
> - we don't need to provide /usr/include/schily/.... in order to deliver
> librmt, star and friends.
If you like to split the case in order to make it easier to understand, you are
correct.
> Insisting on delivering these interfaces makes them a roadblock to getting
> your code integrated.
I am not insisting in delivering these interfaces with the first integration
step. I am just defending against people who seem to be interested in
preventing this next step to happen at all.
> You have a Sun engineer willing and able to help you, and a community group
> which (as far as I can see) is more than happy to help as well, and you are
> insisting that Interfaces (note the "I") be delivered when they are not
> actually required for Joe Random User to make use of star et al.
Please read the mails in this thread again from my view. If people start a
discussion that tries to prevent the next step, I need to reply.
> > I mentioned several times that there is already /usr/include/ast/ which
> > includes
> > interfaces used by a single program (ksh93). Libfind and other libraries
> > offer
> > innovative interfaces used by several programs that are already on
> > OpenSolaris
> > and it is of interest for a lot of other programs. If you believe that
> > /usr/include/schily/ should not appear in OpenSolaris, please remove
> > /usr/include/ast or explain why ARC discussions are not rule based.
>
> I'm not saying that /usr/include/schily should not appear in OpenSolaris.
>
> What I am saying is that *FOR THIS CASE* the /usr/include/schily
> file list *appears to be* an impediment to getting star et al integrated.
I mentioned yesterday already that we can of course split the case if it is too
complex to be handled in a single step.
If some people try to foredoom the next logical step, I need to reply.
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
