This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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: [fortran,patch] Creating a common header to the front-end and runtime library


> I think it's a clear win.  Note that the library needs the compiler to
> be built, not the other way round, so it might make more sense to put
> the common file in gcc/fortran.

Yes. I put it in the library because I saw it as a bunch of
"characteristics of the library" that the front-end needed to know.

> I see that you haven't added Makefile rules for the dependency.

Very good point. For the front-end, they need to be added to
Make-lang.in (everywhere gfortran.h is), and I guess for the library
they are automagically handled, aren't they?

>  With my supposed change you could do without
> cross-directory dependencies (just rebuild the library everytime the
> compiler changes), but this is far from optimal.

I think the right answer is beyond what a dependency system can do.
When you change the compiler, only you know whether it will affect
code-generation in a way that will matter for libgfortran. Since very
few changes actually affect the building of libgfortran, I suggest
that we keep the current system (no dependency; if you know you
changed something that requires rebuilding libgfortran, delete that
directory) except for adding dependency on the common header. How does
that sound?

> One alternative approach that I could think of is having a compiler flag
> that allows the compiler to dump a header file for the library.  Then,
> while building the library you do
>   gfortran --dump-compatibility-stuff > include/libgfortran_fe.h
>
> This wouldn't solve the dependency issues, though.

Too heavy for this particular task, I think.

FX


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