Sh or Makefile for medium projects, which to use?

Help
1

Hi, I have 3 small, very basic projects. The first one reads and creates jpeg/png images, the second reads csv files similar to what panda -python would do with some basic statistical analysis, and the third one creates simple graphs of static functions/animation in SVG format, but I don’t know if it would be better to use sh or Makefile.
All my scripts use sh, but I see that on GitHub they use Makefile in many cases, which do you recommend?
the script i use for read/create images:

#!/bin/bash

Opciones de compilación

GCC_OPTS=“-O3 -march=native -funroll-loops -ftree-vectorize -floop-interchange -floop-strip-mine -floop-parallelize-all -floop-block”
GFORTRAN_OPTS=“-c -fopenmp $GCC_OPTS -fopenmp-simd -Jobjetos” # El flag -J especifica dónde guardar los archivos .mod
MPI_OPTS=“-fopenmp $GCC_OPTS -fopenmp-simd -Jobjetos” # También lo añadimos aquí para los módulos MPI

Directorios

MODULE_DIR=“modulos”
OBJ_DIR=“objetos”
mkdir -p $OBJ_DIR # Creo el directorio de objetos si no existe

Archivos fuente en el directorio de módulos

C_SRC=“$MODULE_DIR/imagen_lee_crea.c”
FORTRAN_SRC_1=“$MODULE_DIR/interface_FtoC_imag.f90”
FORTRAN_SRC_2=“$MODULE_DIR/poo_IMG.f90”
FORTRAN_SRC_3=“$MODULE_DIR/aqui_manipula_imagenes.f90”
MAIN_PROGRAM=“image_processing.f90”

Archivos objeto (se almacenan en la carpeta objetos)

C_OBJ=“$OBJ_DIR/imagen_lee_crea.o”
FORTRAN_OBJ_1=“$OBJ_DIR/interface_FtoC_imag.o”
FORTRAN_OBJ_2=“$OBJ_DIR/poo_IMG.o”
FORTRAN_OBJ_3=“$OBJ_DIR/aqui_manipula_imagenes.o”
EXECUTABLE=“ejexuta”

Librerías

LIBS=“-ljpeg -lpng”

Compilación

gcc $GCC_OPTS -c $C_SRC -o $C_OBJ $LIBS
gfortran $GFORTRAN_OPTS $FORTRAN_SRC_1 -o $FORTRAN_OBJ_1
mpif90 -c $FORTRAN_SRC_2 -o $FORTRAN_OBJ_2 $MPI_OPTS
gfortran $GFORTRAN_OPTS $FORTRAN_SRC_3 -o $FORTRAN_OBJ_3
mpif90 $MPI_OPTS -o $EXECUTABLE $MAIN_PROGRAM $FORTRAN_OBJ_1 $FORTRAN_OBJ_2 $FORTRAN_OBJ_3 $C_OBJ $LIBS

Ejecutar el programa

export OMP_NUM_THREADS=2
time mpirun -np 2 ./$EXECUTABLE

Here are some examples:
1.

mandelbrot_colo
mandelbrot_colo1000×1000 30.8 KB

2.image .svg

program generate_sin_svg
use svg_plot
use svg_module
implicit none

TYPE(svg_properties) :: props
TYPE(svg_pro_Text ) :: protex
integer, parameter :: n_points = 200
real(8) :: ax(n_points+1,5)
real(8) :: x(1:n_points+1), y(1:n_points+1), dx , x_start, x_end,t, dt
integer :: i,j
real(8), parameter :: pi = acos(-1.d0)
real(8) :: xc,yc,rc

call svg_head(15, 8.d2, 6.d2, “perro”)
call define_svg_properties(“ejemplo2”, props)
call define_svg_properties(“ejemplo3”, props)
call define_svg_properties(“Titulo02”, protex)
rc = 1.d2
do i=1,10
props%stroke_width = 0.5d00 + 0.1d0i
props%stroke = rgb_rand()
props%fill = rgb_rand()
props%stroke_dasharray = [2.d0, 1.d0,0.d0+ 0.5d0i]

 xc = 4.d2 + rc* cos(2*(i-1)*pi/10.d0)
 yc = 3.d2 + rc* sin(2*(i-1)*pi/10.d0)

props%stroke_linecap = “round”
CALL store_svg_properties(“ejemplo2”, props)
CALL svg_rect(15,2.d1, 0.d0+i*3.d1, 2.0d2, 20.d0,“ejemplo2”)
CALL svg_circle(15,xc, yc, 40.d0,“ejemplo2” )
CALL svg_ellipse(15,xc, yc, 40.d0,20.d0 )
CALL svg_line(15,4.d2,3.d2,xc, yc,“ejemplo3” )
end do

write (,)protex%font_size

call svg_close(15,“perro”)

x_start =0.d0
x_end = 1.d0*pi
dx =(x_end - x_start)/n_points
dt = 0.01d0

rc = 1.d2

do i = 1, n_points +1
t = (i-1) * dx

x(i) =1d0*t
y(i) =cos(3.d0*t) * sin(5.d0*t)  -sin(7.d0*t)*sin(9.d0*t)

ax(i,1) = sin(2.d0*pi*t) + cos(pi*t )*sin(1*pi*t)
ax(i,2) = sin(2.d0*pi*t) + cos(pi*t )*sin(2*pi*t)
ax(i,3) = sin(2.d0*pi*t) + cos(pi*t )*sin(3*pi*t)
ax(i,4) = sin(2.d0*pi*t) + cos(pi*t )*sin(4*pi*t)
ax(i,5) = sin(2.d0*pi*t) + cos(pi*t )*sin(5*pi*t)

end do
call svg_imag(x,y,“polar_t_4t”, titulo = “NaN”)
call svg_imag2(x,ax,“polawdt”, titulo = “Otro NaN”)
end program generate_sin_svg

UPLOAD no admite svg.
svg_creados

2

If you post code, you better use the </> icon :slight_smile: Now the comments in your script are interpreted as markup. But that said, I quite often use small scripts without even any control statements to build small programs. While I appreciate Makefiles, it takes longer to get these right than writing the typical four or five compile/link statements. But then these programs tend to be very ad hoc. I would say, if you want to share your programs, then Makefiles are the way to go and they wil definitely be useful if your program grows beyond a handful of files.

1 Like
3

Hey hey. I’d say this depends on the size and purpose. For some scripting (e.g., to conduct one quick piece of analysis), I put the compilation and linking options in a bash file. However, as soon as you’re dealing with multiple module files and intend to distribute it, creating and sharing a makefile starts making more sense, as @Arjen already pointed out. Another thing you may want to check out is using the fortran package manager. I’ve found it to be quick, easy and clean to work with for projects of varying sizes.

4

You could just let things evolve naturally without over-engineering… e.g., as soon as your ./build.sh starts feeling inadequate, you can easily convert it to a Makefile.

And btw, a better shebang would be: #!/usr/bin/env bash .

2 Likes
5

I would recommend the Fortran Package Manager fpm to replace any and all makefiles and build scripts, especially for small and medium projects. Makes Fortran a delight to work with.

No need to maintain those pesky scripts or makefiles any longer. We did have cmake and meson before, but fpm is :chefs_kiss:.

1 Like
6

One can make a script to generate a make file given the name of a compiler and a list of source files. A Python script I use is here.

7

Makefiles can still be handy for other things; downloading data sets, executing plotting scripts, running code polishing tools, etc… You can invoke fpm in the Makefile too.

1 Like
8

I would recommend not to start with Makefiles at all. While still handy for many things, there are better higher level tools available which you can choose depending on the complexity of your build:

  • Simple builds, like your projects (note, the simplicity of the build does not depend on the size of the project): use fpm, which is really the best building tool for Fortran to start with.
  • Complex builds (multiple languages within the project, need for conditional compilation, preprocessing, etc.): use CMake or Meson. The entry barrier is higher, but they allow for a higher build complexity.

Ps. You might be interested in cookiecutter-fortran-project, a Fortran project template generator, which you can use to generate a fully featured Fortran project following best practices for fpm, CMake or Meson. (Disclaimer: I am the main author of this template generator)

2 Likes