Issue 7971

Summary: alias dmake='dmake product=full' does not survive subshell invocations
Product: Build Tools Reporter: chris
Component: codeAssignee: foskey
Status: CLOSED FIXED QA Contact: issues@tools <issues>
Severity: Trivial    
Priority: P4 CC: issues
Version: 643   
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: PATCH Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
Patch against set_soenv.in (branch SRX643_OO) none

Description chris 2002-09-30 11:53:27 UTC
The build system uses a product variable to select the type of build to be
performed.  AFAICS, this is only changed in SO builds, and OOo must use
product=full.  If dmake or build.pl is not run with 'product=full' on the
command line, the build runs for quite a while (but placing output in the wrong
directory) and then stops with a link error that is not obvious that the
'product=full' was missing from the command line.

The product name is set by defining an alias for dmake and build like this
(example from Linux w/gcc3):
alias dmake "dmake product=full"
alias build "perl $SOLARENV/bin/build.pl product=full"
alias nmake "dmake product=full"

The problem with this, is that environment variables survive nicely across
subshell invocations (even from e.g. tcsh to bash), but aliases do not (even
tcsh->tcsh).  A look through settings.mk reveals that the product can equally
easily be specified using a PRODUCT environent variable instead of an alias.  

Patch is attached.  The new *.Set looks like this:
setenv PRODUCT "full"
[no alias for dmake is needed on Unix any more]
alias build "perl $SOLARENV/bin/build.pl"
alias nmake "dmake"
Comment 1 chris 2002-09-30 11:54:41 UTC
Created attachment 3016 [details]
Patch against set_soenv.in (branch SRX643_OO)
Comment 2 foskey 2002-10-08 12:55:39 UTC
Patch has been tested and applied.
Comment 3 chris 2003-02-24 14:17:11 UTC
Verified & released in 1.0.2; closing