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] | |
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.
Cheers, - Tobi
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |