Whilst trying to get my head around the Fortran code I have I am also trying to understand how the
makefile system works.
The following is the
makefile I have inherited (I have removed comments and sections that I know serve no purpose for the system I am interested in.
My questions are initially…
- does the second
.suffixes: replace the first one or append to it?
- Is this a good example of a
makefile? It looks overly confusing to me.
- I’m going to need to add in the compiling of the
modules.f file; is this an easy addition?
.SUFFIXES: .out .o .c .e .r .F .f .y .l .s .p .vmsf .for .vmsc .com
.f.o: ; $(FOR) $(FFLAGS) -c $*.f
if [ ! -d $(HOME)/bin ]; then mkdir $(HOME)/bin; \
else true; fi
for i in $(PROGS);\
$(MV) $$i $(HOME)/bin;\
dummymain: dummymain.o stelcor.o
$(FOR) $(FFLAGS) dummymain.o stelcor.o -o dummymain
$(RM) *.o core
$(RM) $(PROGS) datefile
- the make manual describes suffix rules as old-fashioned: Suffix Rules (GNU make), since
.SUFFIXES is a target having multiple will append (still
.f is present in both)
- make is quite powerful, but really a mess when building Fortran projects with module files, there are couple of things I would consider a bad design in the rules:
- variable for the Fortran compiler is
FOR, most build systems have converged to using
- suffix rules are discouraged by make manual
- clean and realclean targets remove files unrelated to makefile
- install target does move, instead of copy
- user cannot use
DESTDIR to control install location
- to add
modules.f you have to declare the correct dependencies between your rules, all other source files will probably depend on
modules.f, therefore you need to declare:
dummymain.o stelcor.o: modules.o
Make is a powerful but difficult language, especially if you consider that there a plenty built-in rules and variables, different variable kinds with slightly different behaviour and the challenge to build rules with multiple outputs, like Fortran module files.
I stopped using make for my projects, not because it can’t get the job done, but because the learning curve is quite steep to properly learn make to avoid making hard to debug mistakes. You can pull off pretty decent stunts in make, but they are hard to explain to anybody else.
My recommendation would be to switch to a high-level build system while it still easy and you haven’t invested too much time building your own makefile. I can recommend three build systems I’m usually using in my Fortran projects (you only need one, of course)
I also have created a cmake-based skeleton for Fortran: GitHub - MarDiehl/fortran-skeleton: Cmake-based fortran skeletons. I always use this if I want to prototype something quickly.
Thanks for this.
I am using Geany across all platforms and only realised today that it handles the make for me. I believe it must be using the makefile in the directory, but does offer templates I can follow. Thank you for your suggestions. I explored each one today but feel I might have to stay with make only because I am not the only person working with this system and I don’t want to build a system that excludes others from working with me; or makes their lives more difficult.
Fair enough, I have used make myself for quite a while because everybody was using it.
I found that a lot of people using make have an expectation, which doesn’t match what make actually does or can do, and this can be dangerous (in the sense of wasting time on debugging makefiles). Eventually, it turned out everybody was happy to move to meson and/or fpm, because make was our constant source of build problems and unhappiness.
I also wrote a bit on make at An introduction to make - Fortran Programming Language, covering some of the more interesting aspects of the language. Don’t get me wrong, I really like make as a language, but I think there are better ways to build Fortran projects. Still, if you have any questions regarding make, feel free to ask them here, I’m always happy to answer.
Thank you and please do not consider my reply a brush-off. I am working with a couple of astrophysicists who are not experienced programmers at all but have developed years of experience on this particular code. They are brilliant astrophysicists (especially my supervisor - who is NOT reading this) but it is their code that I am altering - and I am relatively new to this game!