[m-dev.] mmake ignoring LDFLAGS

[Simon Taylor]

On 29-Oct-2004, Michael Wybrow <mjwybrow at cs.mu.OZ.AU> wrote:
> On Thu, 28 Oct 2004, Ian MacLarty wrote:
> >>
> >>Again, neither of these suggestions help.

The interaction between (m)make and environment variables is fairly
poor.  You could argue that all assignments of the form `Var ='
in scripts/Mmake.vars.in should be conditional on `Var' being
previously undefined.

> >Try putting EXTRA_MLFLAGS=-L/sw/lib in your browser/Mmake.browser.params.
> 
> Yes that does cause it to link correctly, but it then bombs out later when 
> it tries to include the readline headers because it is also discarding the 
> CPPFLAGS variable:

There is no such Mmake variable.  See the user guide.
 
> ../scripts/mgnuc --grade reg.gc --no-mercury-stdlib-dir --no-ansi --no-check
> -- -I../boehm_gc -I../boehm_gc/include -I../mps_gc/code -I../runtime 
> -I../library -I../library/ -I../browser -g -DMR_NO_BACKWARDS_COMPAT
> -DMERCURY_CONF_BOOTSTRAP_H -c mercury_trace_readline.c
> -o mercury_trace_readline.o
> mercury_trace_readline.c:27:35: readline/readline.h: No such file or 
> directory
> mercury_trace_readline.c:37:34: readline/history.h: No such file or 
> directory
> 
> So I can probabley add an EXTRA_MCFLAGS with "-I/sw/include" in the 
> Mmake.browser.params, but surely the correct thing is for the configure 
> script to preserve the values of these variables, since these are used 
> when testing for readline in the configure script, they should be used as 
> build options throughout the entire build process.

I don't see why not.

Simon.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------