Hi Darren,
On 05/09/07 14:30, Darren J Moffat wrote:
Gavin Maltby wrote:
- if NIGHTLY_OPTIONS from the env file selects 'd' for dmake then:
. /opt/teamware/bin is added to the PATH
. if DMAKE_MAX_JOBS is not already set then groks this out of
~/.make.machines (otherwise every dmake parses that file);
. if no setting in .make.machines is found for the current
host then defaults to #cpus * 4
. sets DMAKE_MODE=parallel
the opensolaris.sh env file already does part of this.
I'll take a look. I confess to never having used opensolaris.sh, SWAN-enabled
as I am.
- if BUILD_PROJECT is set (either from the env file or simply via the
shell)
then start a new task in that project; always show the project and
taskid for the build
Sounds related to 6439703.
Yes, the default env file behaviour of setting it to the empty string
sucks. As you say in that CR it should be commented out by default.
I also quite fancy a set of default project choices from which we
select the first match (if the env file did not select a project).
Something like:
build.<login>
build
The script will run projects(1m) and apply the first in the above list
for which you are a member. Build system maintainers can create
some of these standard project names as they wish. In some
systems users will already default to project user.<login>, but
I'm thinking of other system like my desktop in which I like
to restrict building to a project called "build" which has
a reduce cpu share compare to user.gavinm so that interactive
usage doesn't suffer too much when building.
- exports ISBLDENVSHELL=1 to the subsequent shell, so that its rc
files can tune behaviour for a build environment
This would be useful for nightly as well.
I guess I was thinking mostly of interactive shells. But I guess
a bunch of shells get started during build one way or another.
Thanks
Gavin
_______________________________________________
tools-discuss mailing list
[email protected]
