https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119213
Xi Ruoyao <xry111 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |xry111 at gcc dot gnu.org
--- Comment #8 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Robert Dubner from comment #7)
> 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?
Or move ec.h etc. into gcc/cobol, and in libgcobol add
-I$(srcdir)/../gcc/cobol. It'd be like how libgcc uses headers in the gcc/
directory.
