>> 1. How exactly are the Mamfiles used? Or is this just files
>> included with the ATT distribution for their build system.
>
> Yes, it's coming from the upstream sources... remember we don't want to
> fork() the upstream sources and that includes random stripping, file
> deletion, renaming of binaries just because someone doesn't like that
> name (we had that discussion for "shcomp" a while ago) and all the other
> "funny" ideas what could be done to the codebase (like making all
> upstream sources "cstyle" clean etc.) ...
I was merely asking what these files are and not asking for them to be
changed, removed, etc. In general for ON, we don't like to see files
checked in which serve no purpose in the build process unless they're
there to document something about the source (for example, a README
which explains the source layout).
I'm not trying to reopen this ON-versus-SFW debate here but the
discussion around these files is precisely because you're trying to
integrate this into ON. Consolidations such as SFW work much more in a
pass-through mode - the source comes from upstream, undergoes a small
amount of change (if any at all) and then is compiled and packaged via
some sort of mechanism (perhaps a Sun-supplied master Makefile and the
open source project's own ./configure script).
>
>> 2. I agree with Jim Carlson about the setting of SHELL in the
>> various ksh-related Makefiles. At this time, I think using the
>> crufty old /bin/sh is the right thing to use for consistency,
>
> "Consistency" is IMO no good argumment in this case. We use ksh to
> simplify things and make the code smaller and better understandable.
> IMHO a clean design using ksh is better than a painfull and unreadable
> amount of hacked bourne shell code garbage.
That certainly is a good argument if bourne shell implementation is
unreadable. But there seem to be some Makefiles where I didn't see any
ksh93 constructs at all, or minimal ones at that. For example, why the
changes to libcmd's Makefiles to use /bin/ksh?
>> unless some compelling reason can be shown where a ksh (or
>> ksh93) construct greatly simplies things.
>
> At least the Makefile.testshell part won't work without ksh and the
> include files and l10n generation depends on a lesser extend on ksh
> (which means that all Makefiles in
> usr/src/lib/lib(shell|cmd|dll|pp|ast)/ depend on it). Both could be
> re-implenented using the plain bourne shell at the expense of making the
> code really difficult to understand and unreadable (I already agreed to
> adjust the directory creation in usr/src/lib/libast/ at the expense of
> cleanness in the code and I am not happy about it (it's less
> understandable and slower) ... ;-( ).
>
> I would really strongly perfer to keep SHELL=/bin/ksh - it may even
> provide the "proof" that we can (later) to a tree-global switch to a
> POSIX shell without causing any harm.
For the ksh93 specific Makefiles, I'm OK with leaving that in although
my suggestion is to only put it in where you're actually required to
use ksh93.
>> 3. With respect to the *.so library links and the the lint
>> library, I think including these in an internal package is fine
>> but I do not believe they should be actually included in any
>> metacluster at this time. From my understanding of the
>> contents of the SUNWastdev packages, that also holds true for
>> it as well.
>
> Erm, the primary purpose of the "SUNWastdev" package is to deliver AST
> development tools to /usr/ast/bin/. It was not intended to become a
> dumping ground for everything.
Thanks for the explanation. I went back to PSARC 2007/035 and it does
seem that this package should contain just the components presented in
that case.
But I do have one question for SUNWastdev. If the *.so library links
for libshell, libast, libdll, and libcmd (and libpp, for that matter)
are not supplied, is this package actually usable by anyone? Let's
leave out the ON developers but rather focus on the end-developer who
is wishing to use the AST development tools. Do these tools depend on
linking against the currently project private libraries? Put another
way, should this package me an internal-only package right now because
the end-developer cannot use it given the commitment level that was
ARCed?
>> When the commitment level of these things are
>> raised in the future, then it makes sense to include them in a
>> package like SUNWcslr, SUNWarc, a metacluster, etc.
>>
>> Please understand that this isn't a criticism or knock against
>> ksh93 - the same is true of internal tools, libraries, etc as
>> well.
>
> I don't take this as "criticism" or "knocking against ksh93" (nor do I
> think that you or James have anything against ksh93 etc.). I know the
> rules... but I was hoping for some kind of "escape route" since many
> people are curious and like to play around with the new libraries.
> Unfortunately the rules do not seem allow some kind of curiousity... ;-(
People who want to explore their curiosity in this space can do so by
downloading the ON source tree and compiling their programs within
there. But it does a disservice to other using the end-user
distribution if they begin using those interfaces and then they change
in an incompatible way.
>> And in those cases, have you added the
>> appropriate Copyright to each of those files?
>
> What do you mean with "appropriate Copyright" (note: I am not a
> lawyer... (and usually I try to hide under my desk when the license
> flamewars start...)) ? AFAIK we do not need (and should not need) to add
> any CDDL license to the AST codebase since we have a permission to
> contribute any Solaris code to upstream (Mike Kupfer can explain that
> AFAIK better) under their own license ("CPL") which AFAIK covers any
> tree-local modifications. The new tests and demo code has a CDDL
> license.
I know you don't want to deal with licenses so my suggestion is to
contact Bonnie Corwin and explain precisely what files you're changing
and in what way. It's my understanding that the usual thing is
Don't add a Sun copyright to upstream files that you're not
changing.
Do any a Sun copyright to any files being created that aren't
coming from upstream (for example, OpenSolaris specific
Makefiles.)
Do add a Sun copyright to files which have a significant
change. The definition of the latter is sometimes hard to
define but changing it to make it compile or work under
OpenSolaris clearly falls in the "add" category. In any case,
please check with Bonnie.
>> usr/src/lib/libast/amd64/Makefile
>>
>> Line 31 - Is there a reason you're only using the minor part
>> here rather than the whole $(RELEASE) string? Is there some
>> standard here that ksh93 uses with different OS versions?
>
> See may reply to James Carlson's email
> (http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2007-February/002225.html).
> Basically the upstream code uses this as a platform identifer and we use
> the same algorithm to provide the same value in this case (the code
> doesn't build without a value and I don't want to pass a hardcoded
> value).
I saw the response but it still sems short-sighted on including part of
the `uname -r` value but not the rest. What happens if we ever produce
a SunOS 6.0? Will ksh93 identify itself then as "sol0.i386", etc?
>> usr/src/lib/libcmd/common/mapfile-vers
>>
>> This is showing up only under "Old". Are you removing it?
>
> "mapfile-vers" should be in the libraries's base directory to avoid that
> this may get lost during source updates. The common/ subdir should for
> the upstream sources only (only exception is the additions to the demo
> code and test suite (e.g. the test to watch over the getconf
> compatibilty (usr/demo/ksh/tests/sun_solaris_getconf.sh)) ).
I didn't explain my question well. Are you planning on moving
usr/src/lib/libcmd/common/mapfile-vers to
usr/src/lib/libcmd/mapfile-vers and updating the file? Perhaps this is
a question for April since it's a Teamware operation.
I don't quite understand why you're making the connection, though, with
upstream and the common directory. If you look at
usr/src/lib/README.mapfiles, you will see that it specifies the usual
place for "mapfile-vers" is under the "common" subdirectory. The fact
that most of the files under that come from an external, upstream
source seems irrelevant to me.
> General note on the wordexp.c diff: The new version of the workexp() is
> a cloned version of the old code and then modified to work with ksh93
> and therefore has cloned all the cstyle and other coding layout bits
> from the original. The idea of copying the whole function was to avoid
> having a zillion of #ifdef/#else/#endif in there which would make the
> code more or less unreadable or normal human beings.
> /opt/onbld/bin/cstyle however doesn't complain about the current vesion.
> [snip (moving this to a seperate email)]
Understood but I think it's still worthwhile to clean up the additional
"cloned" code.
I didn't see another thread started on this but in addition to the
cstyle changes, I did ask about the following but wasn't clear what the
answers were.
Lines 217-226 - Could you provide more details here? Is
/usr/lib/libc/libc_wordexp_commands another interface that can
be customized by users?
Lines 308, 310, 312 - Is there any header file which #defines
these ksh93 exit codes?
>> usr/src/lib/libpp/mapfile-vers
>>
>> Line 29 - I don't think this comment is really necessary
>> (almost all of the other mapfiles are also generated by hand.)
>
> Erm, all other AST mapfile-vers stuff is created more or less
> automatically and then verified by hand (exceptions include libpp and
> libshell (where I had to export all |b_()| functions to avoid a
> screw-up)).
Sorry, what I meant was that all the other ON mapfiles are also
generated by hand and calling it out here didn't make sense.
>> usr/src/lib/libshell/common/data/solaris_cmdlist.h
>>
>> Line 26 - The file is missing a #pragma ident.
>
> Uhm... this file "pretends" to be an AST source (well, it's added by the
> "ksh93_solaris_builtin_patch.diff") and AFAIK doesn't need a "#pragma
> ident" (AFAIK this is some kind of border case... ;-/ ).
I think every header file that's checked in should include the "#pragma
ident" unless this file is unmodified from upstream.
>> usr/src/lib/libshell/misc/buildksh93.ksh
>> usr/src/lib/libshell/misc/buildksh93.readme
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Did you read the README and the **WARNINGS** in the script itself ?
> "buildksh93.ksh" is the way how we build the external includes and is
> highly specific for the putback. The script is even modfied for each of
> the updates we did during during development and the script is crafted
> specifically for that version of the ast-ksh.YYYY-MM-DD.tgz package. If
> there is anything we can do really wrong than it's:
> 1. Loose this script. At that point we loose our abilty to update the
> codebase in OS/Net
> 2. Use the wrong version of the script on the wrong AST sources - that's
> a wonderfull method to invite bugs to creep into the headers and
> codebase.
> Therefore *NO* (and please no bickering about this part - much testing
> went into "buildksh93.ksh" and loosing it would more or less FATAL for
> this project). At least this script should really stay here to be in
> sync with the putback (I am willing to debate the case about the *.diff
> files but "buildksh93.ksh" is really off-limits for "place it
> elsewhere"-discussions).
Sorry, modulo getting the build machine's environment setup correctly
(for example, perhaps adding SUNWastdev to the machine), why isn't
building ksh93 as simply as "cd usr/src/cmd/ksh ; make"? Yes, there
are dependent libraries but I'm confused as to how this script is
helpful as part of building ON.
Or is the script that's used to generate the files which are eventually
*checked in* to ON?
If it's the latter, then I see this as being in the same boat as the
*.diff files. They do deserve a home, perhaps on the ksh93 OpenSolaris
project page on opensolaris.org or genunix.or but it seems we're
talking about files that aren't useful for the building of ON itself.
>> usr/src/lib/libshell/misc/ksh93_solaris_builtin_patch.diff
>> usr/src/lib/libshell/misc/ksh93_solaris_builtin_patch.readme
>>
>> I don't believe these files should be putback to the ON gate.
>> It makes sense to keep them on a project-specific website.
>
> Umpf...
> ... this is per-putback information. It is going to change per putback.
> How should an external project side track this and all branches made
> from the main OS/Net tree ? And there is no gurantee that the project
> webpage will be available in ten or more years which will generate a
> serious problem for the maintainers. We already had that problem for
> dtksh and except the generic "we try to avoid that mistake in the future
> for OpenSolaris" noone has proposed a working alternative which tracks
> the progress of ksh93 in OS/Net including all branches.
Again, please don't draw any conclusions on what happened with dtksh.
That wasn't part of ON and is, I think, not a representative example to
draw conclusions from. What I think is a better example is the source
which has an active upstream.
I think we're going to have to agree to disagree here on the value of
incorporating these into ON itself.
>> usr/src/pkgdefs/SUNWcsu/prototype_sparc
>>
>> Lines 50-51 - What is the reason for shipping a 32-bit version
>> on SPARC? Can ksh93 be used to read 32-bit core files or
>> processes? :-)
>
> There are several reasons including:
> - ksh93 supports (loadable) binary plugins which may itself rely on
> other shared libraries which may not be available as 64bit versions. In
> those cases a 32bit ksh93 is needed. I am waiting for a sponsor for
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6474270
> ("isaexec and magical builds") (see request-sponsor queue) to make
> "isaexec" adjustable for applications which need such a functionality
> (via restricting the list of ISAs based on accept and/or reject filter
> environment variables).
So how does a SPARC user use ksh93 in that case? Do they code their
scripts to use /usr/bin/sparcv7/ksh93 directly?
BTW, what is the API for creating those binary plugins? Is it an open
API as covered by the PSARC case?
> - We need libshell&co. around for future consumers like the various
> tools currently wrapped in "alias.sh" (this includes things like
> /usr/bin/test etc.), "shcomp" (shell script compiler), /usr/bin/sleep
> (using a 64bit binary for this is IMO an overkill), /usr/bin/printf etc.
> and obmitting the 32bit shell would not be wise in this case (for
> example: how else can we test the libraries then ?).
Yes, but those components are not part of this case, correct?
dsc
