Joerg Schilling wrote:
> "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.
>
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.
>
>
>>> 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
>
The case before ARC at the moment makes no mention of any of these other
headers.
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.
>
>
>> 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".
>
No, not really. If you want to create a new portability layer, then
please propose a new case. This case is about the rmt and star
application programs, and the supporting librmt.
Going through the case materials further, I'm pretty unhappy about the
paucity of documentation in librtmt(3). It contains references to
things like rmtinit(), but no actual documentation -- not even a
function prototype. This is insufficient information for ARC to
properly review these APIs, nor for developers to use them.
Now, here's the punchline:
1) If you want to make this case about integration of star and rmt, with
librmt as a project private API, then please don't ship the headers or
librmt(3) man page. (In which case, I'm happy, and it looks like this
can proceed with minimal further controversy.)
2) If you want to make this case about creation of a new portability
layer, then please say so, so that your case can be derailed for further
review. (Note: derailed != denied, it just means that the process is a
full review, rather than a fast-track.)
3) If you want this case to mean something else entirely, then please
enlighten us, because at least this member isn't clear what exactly
we're supposed to be reviewing right now.
-- Garrett
