illumos gate

Would it be a good idea to have $(ROOT)/usr/ast/bin and /usr/ast/bin? Otherwise, I like it. (consider that code review, if that helps)

Updated as per your suggestion:
http://pkgdev.openindiana.org/hg/mq_onnv-gate/file/ef5865cafe35/oi-issue-306-ast_msgcc

I like it too, with the update. Please show a nightly build log with this and start the process to integrate. :-)

Erm...
1. ... the AST msg localisation tools are required for shell script localisation in ksh93 and bash, e.g. for $"..."-style literals and applications which use libast for localisation support. Removing them will pretty much kill such support
2. The tools could be moved to /usr/bin/. /usr/ast/bin/ was only chosen for political reasons (partially to declare to declare the tools and output formats as private, otherwise we would've to describe the whole POSIX l10n catalog format in an ARC case (the format itself is supported by libc but was never formally ARC'ed))
3. The reason why the tools and scripts for localisation are shipped with Solaris was that it is not allowed in OS/Net to execute binaries which are part of the proto area.

Answers to Roland's points:

1. We're not removing these utilities. so don't worry about that. In fact, what we're doing here is using the version of the tools that we just built rather than relying on whatever happens to be lying around on the build system.

2. We're not talking about moving tools. That's a totally different topic, and out of scope for this change.

3. I've never heard of any such rule, and even if I did, I'd say it sounds bunk. HOWEVER, normally this would be a bad idea because your proto area could (in theory, not ever possible with ON) be a cross-system where you can't run binaries. But this is a shell script.

In retrospect, I think the right answer is something different than proposed here: Specifically, we should "build" msgcc in the local directory, and use it from our source/build tree, not from the proto area. This build would be a "build-system-native" version of msgcc, whereas what we built for the proto area is a "target-system-native" version.

In retrospect, I think the right answer is something different than proposed here: Specifically, we should
"build" msgcc in the local directory, and use it from our source/build tree, not from the proto area. This
build would be
a "build-system-native" version of msgcc, whereas what we built for the proto area is a "target-system-native"
version.

Erm... we would have to do the same with ksh93 then, too. There is no gurantee that new versions of "msgcc" in the tree work with old versions of ksh93. "msgcc" has a couple of old workarounds for old ksh93 bugs which are likely going to be pulled out next year. Depending on which ksh93 version then sits on the build system it may cause trouble (on the other side it is "only" used to build l10n catalogs... it is not exactly critical how the output looks in the case of missing workarounds as long as ksh93 doesn't dump core. Distributions are anyway needed to build OS/Net, then install the bits and then build+install again to make sure all stuff works properly).

That was one of the reasons why we shipped SUNWastdev as package - first OS/Net didn't had the utilities and then there was the fear that the use of newer features on older build machines may create issues. That's why JBeck enforced the rule described in [3] after April asked about this.