Joerg Schilling wrote: > "Garrett D'Amore" <gdamore at sun.com> wrote: > > >>> 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. >>> >>> >> Okay. But that isn't what we've been asked to review. What we've been >> asked to review is a couple of utility programs and a supporting >> library. Creating a portability layer and exposing that to the rest of >> ON was not part of the case materials. >> > > Well, I remember that a similar case (made for ksh93 integration) did already > add such a portability layer although (using the same rules as for star) the > ksh93 case needs those files only for private interfaces. > Are you asserting that these private ksh header are being shipped in /usr/include? > The star integration adds more than private interfaces, note that librmt is > supposed to be used by ufsdump/ufsrestore too..... > > > >>> /usr/include/schily/utypes.h >>> /usr/include/schily/param.h >>> >>> >> The case before ARC at the moment makes no mention of any of these other >> headers. >> > > I don't know why. > Well, if you don't know, I don't know either.
>> I suppose one could argue that they are an implementation detail. But I >> feel like we (the ARC) have not been presented with the full picture. >> > > See above, it they are an implementation detail, then /usr/include/ast/ does > not belong into Solaris for the same reason. > I believe ast has an associated public library and at least some of those headers are need to link against that library. If these headers are completely implementation, well, we blew it (or it comes from a time when that was the mantra). - jek3
