Don't require external ast msgcc
External /usr/ast is required for the/usr/ast/bin/msgcc script and related executables msgcpp and msgen, which are run for the _msg target of the ast libraries. This is the only dependency on /usr/ast. These are the same as delivered by usr/src/cmd/ast/msgcc. The following trivial change uses the copies in proto.
diff --git a/usr/src/lib/Makefile.astmsg b/usr/src/lib/Makefile.astmsg --- a/usr/src/lib/Makefile.astmsg +++ b/usr/src/lib/Makefile.astmsg @@ -47,8 +47,8 @@ ASTMSGCATALOG= $(ROOT)/usr/lib/locale/C/LC_MESSAGES/$(MSGLIBNAME) $(DO_BUILD_AST_CATALOGS)ASTMSGCC= \ - PATH="/usr/ast/bin/:/bin:/usr/bin" \ - /usr/bin/ksh93 /usr/ast/bin/msgcc >>msgcc.out 2>&1 + PATH="$(ROOT)/usr/ast/bin/:/bin:/usr/bin" \ + /usr/bin/ksh93 $(ROOT)/usr/ast/bin/msgcc >>msgcc.out 2>&1 ASTMSGS= $(OBJECTS:%.o=msgs/%.mso)
Updated by Albert Lee about 10 years ago
Updated as per your suggestion:
Updated by Roland Mainz about 10 years ago
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.
Updated by Garrett D'Amore about 10 years ago
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.
Updated by Roland Mainz almost 10 years ago
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"
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  after April asked about this.
Updated by Keith Wesolowski over 6 years ago
- Category set to tools - gate/build tools
- Status changed from New to In Progress
- Assignee set to Keith Wesolowski
- Difficulty set to Bite-size
Regardless of whether we want to build a separate native ksh93 and msgcc, Makefile.astmsg needs to stop hardcoding the path to the tools and learn to use $(MSGCC) and $(ASTBINDIR) from Makefile.master.