This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: i370 port - constructing compile script


Ok, I've now reached a new milestone - the mshort.h which
redefines all the long names into ZZZ_123 etc is now automatically generated as part of the build process.


The libiberty and gcc aren't split yet, but I'll probably defer
that to gcc 4, and see if I can simply reproduce what I have
with 3.4.6 first.

But there are some things I want to change in the 3.4.6
before starting that.

There are some files that are being automatically generated
as part of the build process, which I would like to stop.

gcov-iov creates a gcov-iov.h which has a version number
which changes when I change MVS versions.  So I am
thinking of updating gcov-iov.c so that when the target is
MVS, it generates a more fixed format.  Or maybe as part
of the build process I can just put in a
#define GCOV_VERSION 0
Not sure if it's actually being used for anything in my
environment.

gengtype-yacc.c & .h gets created with my new version of bison.
I just want to use the one that came with 3.4.6 instead of
having it regenerated.  Do I need to hide my bison to stop
that from happening?

configargs.h I will just overwrite with something simple as part
of the build process.

gencheck.h is being generated as an empty file, which doesn't
work well on some environments.  I want it to at least have a
comment saying "/* empty file */".  I can put that in as part of
the build script too.

Basically I'm looking for consistent source that won't change
with my build environment.

The raw "MVS source" can then be taken to another environment
to be compiled.

Thanks. Paul.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]