https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119213
Robert Dubner <rdubner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |rdubner at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot
gnu.org
--- Comment #7 from Robert Dubner <rdubner at gcc dot gnu.org> ---
There are two major issues here. I'll put them into two comments.
I acknowledge that CPPFLAGS doesn't belong to me; I used it to solve a problem
before I understood that Make-lang.in gets incorporated with all of the other
Make-lang.in fragments to create the top-level Makefile.
However, I used it to solve a couple of problems. I need advice as to how to
solve them.
First, and foremost: As currently implemented, the host code and the libgcobol
code use the same data structures. Simple example: exception processing. The
gcc/cobol and libgcobol code need to agree on what the exception codes are.
So, that's kept in libgcobol/ec.h, and the gcc/cobol code needs to access it.
Another example: COBOL variables are data structures; that structure contains
information about cbl_field_type_t, an enum that indicates the type of COBOL
variable. The gcc/cobol host code and the gcc/libgcobol code have to agree on
those. So, that information is in libgcobol/common-defs.h, and is accessed by
gcc/cobol code, too.
If I get rid of the -I$(LIB_INCLUDE) that I put into CPPFLAGS, the "can't find
ec.h" errors appear.
I suppose that I could fix this with >>>#include "../../libgcobol/ec.h"<<<
everywhere #include "ec.h" currently appears.
Is that my solution?
