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? 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"
or
PURIFYOPTIONS="[EMAIL PROTECTED] -windows=no" gmake WITH_PURIFY=true
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.
Travis
--
View this message in context:
http://www.nabble.com/Discussion-for-STDCXX-573-tp15072366p15077852.html
Sent from the stdcxx-dev mailing list archive at Nabble.com.
