[mercury-users] Re: Compilation errors with Mercury and GTK--

[Fergus Henderson]

On 05-Feb-2002, Andy Coates <coates_andy at hotmail.com> wrote:
> 
> > >
> > > In file included from skaMain.cc:3:
> > > skaNLP.h:30: `MR_Word' was not declared in this scope
> > > skaNLP.h:30: parse error before `,'
> > > skaNLP.h:36: syntax error before `;'
> >
> >(`MR_Word' is supposed to be defined in "mercury_types.h",
> >which is included by "mercury_imp.h".)
...
> (when compiled into highlevel code, skaNLP.h does not include mercury_imp.h, 
> but mercury.h. Does this change the scope of MR_Word?)

mercury_types.h is included by mercury.h too, so long as
MR_HIGHLEVEL_CODE is defined -- which it should be, if you
invoke g++ via `mgnuc --high-level-code' (you can check
this by adding `-v' or `--verbose' at the start of MGNUCFLAGS).

> If I wish to use the type MR_Word in skaMain.cc should I include 
> mercury_imp.h or just mercury.h?

Including mercury.h will only have any effect with --high-level-code
grades (when MR_HIGHLEVEL_CODE is defined), whereas mercury_imp.h will
define these types in any grade.  So mercury_imp.h is the right one to use.

But the generated header file skaNLP.h is supposed to already include the
appropriate header file to define MR_Word.  You shouldn't need to explicitly
include any additional header files.

The `-save-temps' option to gcc/g++ can be useful for debugging
these kinds of problems -- it lets you examine the code after
it has been preprocessed by the C preprocessor (*.i or *.ii).
The `-dD' option to gcc/g++ is also useful for showing what
macros get defined.  E.g. try putting `-dD -save-temps'
at the end of CFLAGS and examining the *.i or *.ii files.

> Won't this just bring back the problems with namespaces?

If problems with name clashes remain even after you've defined
MERCURY_BOOTSTRAP_H, then you need to figure out exactly what those
problems are, so that we can fix them.

(Or post a complete, reproducible test case.)

> >Try deleting the definitions of MGNUC and ML from your Mmakefile.
> 
> If I do this, how will mmake be able to compile the c++ code?

Ah.  You need to make sure that the C++ code gets compiled with g++,
but that the C code generated by the Mercury compiler gets compiled
with gcc. 

It should be OK to link with g++, so the definition of ML can stay.
But rather than overriding MGNUC, use a different variable,
e.g. MGNUC_FOR_CXX (see patch below), so that it only affects
how .cc files get compiled, not how .c files get compiled.

--- Mmakefile.old	Wed Feb  6 01:33:31 2002
+++ Mmakefile	Wed Feb  6 01:34:34 2002
@@ -20,7 +20,7 @@
 .cc.o:
 	$(CXX) $(HACK) $(CXXFLAGS) -c $<
 
-CXX=$(MGNUC) $(ALL_GRADEFLAGS) $(ALL_MGNUCFLAGS)
+CXX=$(MGNUC_FOR_CXX) $(ALL_GRADEFLAGS) $(ALL_MGNUCFLAGS)
 
 # Due to a bug in g++ 2.7, global register variables don't work in C++.
 # Hence we need to ensure that we don't include the global register
@@ -42,7 +42,7 @@
 #tell mercury to compile the c code using g++
 GRADE=none
 GRADEFLAGS = --high-level-code
-MGNUC = MERCURY_C_COMPILER=g++ mgnuc
+MGNUC_FOR_CXX = MERCURY_C_COMPILER=g++ mgnuc
 
 # tell Mmake not to remove the `.cc' files, so we can look at them (e.g. in gdb)
 RM_C=:

> I presume only 
> the method of using mmc to compile the mercury code, and then using g++ to 
> compile them all together will work.

That method should work too.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------