Travis Vitek wrote:
Travis Vitek wrote:
[http://issues.apache.org/jira/browse/STDCXX-573]
This issue requests that we add purify support to the build system. I'm
trying to decide what the best way to go about this is going to be.
Andrew provided a patch that uses $PURE_OPTS to enable purify and to
provide additional flags. I don't really like adding another environment
variable or flag that does the same thing unless it is really necessary.
By default, purify will look at $PURIFYOPTIONS and $PUREOPTIONS for
additional purify flags.
So I'm considering just using a PURIFY flag to indicate that the user
wants to link with purify, and then providing a default set of flags. If
the user provides PURIFYOPTIONS or PUREOPTIONS, then the defaults will be
overridden.
That would mean that calling `gmake PURIFY=1' would enable purify with the
default options "-windows=no [EMAIL PROTECTED] [EMAIL PROTECTED]". If
you want to override that behavior, you would use `gmake PURIFY=1
PURIFYFLAGS=<FLAGS>'.
Does anyone have any arguments against using this method?
Should I be caching the PURIFYOPTIONS and PUREOPTIONS variables in
makefile.in?
They're environment variables, aren't they? I don't think we need
or want to cache their values. I assume purify itself will read
them from the environment when it's invoked.
If yes, then I'm stuck. I think I would want to allow the user
to invoke make as
gmake WITH_PURIFY=true PURIFYOPTIONS="[EMAIL PROTECTED] -windows=no"
I don't see how this would work in general unless PURIFYOPTIONS
(the make variable) got passed by our GNUmakefile to Purify on
the command line or defined as an environment variable as you
show below.
Is PURIFYOPTIONS the only way to communicate -log-file to Purify?
If it is, it seems that GNUMakefile should append the option to
the variable before executing each target.
or
PURIFYOPTIONS="[EMAIL PROTECTED] -windows=no" gmake WITH_PURIFY=true
This should work in general because this PURIFYOPTIONS is an
environment variable. But I still don't think we should be
expecting the user to specify a pattern like this in their
PURIFYOPTIONS.
The problem is that when writing PURIFYOPTIONS out to the makefile.in [from
GNUmakefile], the $@ gets expanded or stripped. The closest thing I have to
something that works is
&& echo "WITH_PURIFY = $(WITH_PURIFY)" >> $(MAKEFILE_IN) \
&& echo "PURIFYOPTIONS = `echo $$PURIFYOPTIONS`" >> $(MAKEFILE_IN) \
This works well if PURIFYOPTIONS is from the environment, but not so well if
it is an argument to make.
Right. That's the same problem as shell quoting. Sooner or later
you'll end up stripping too many layers of quotes or not stripping
enough.
Martin
