Awesome, thanks!
Iāve also found 460+ source files using and/or defining subroutine get_unit to find a free unit number, by executing an inquire(unit=i,opened=lopen,iostat=ios) in a do i=1,99 loop.
Now that could (and probably should) be changed to open(newunit=...
1 Like
I generally use MIT or BSD. I used to specify code was public domain or use the āunliicenseā but had several requests to change that to BSD or MIT. They said that in their countries you could not put something into public domain, so specifying it was essentially was the same as not specifying a license, which was therefore the same as retaining all rights. Still not positive they were not being excessively cautious but without diving into it too heavily I started using those two primarily unless specifically asked to use another. I sometimes want the license as Fortran code as well as plain text, and the WWW is not always available so I made an fpm plugin for some of the more common licenses
is a single-file version. It has a lot of large modules included that are not shaken so it looks rather large but is quiet simplistic. Keep meaning to make it fancier. If the utility itself is not of interest, the help text lists a number of extensive on-line resources that can help you select a license by answering questions like āis the code open-sourceā . Do you want it to be used without fee in commerical code?" and so on.
But if you are an fpm user, compile the code and put it in your path and you can
enter commands like
fpm license bsd --fortran >license.f90
If you do not set up a config file you usually have to edit the file and add your name, corporation title, etc.
Using a ādivide and conquerā approach it seems like creating github projects for each of the categories as listed by @Beliavsky and creating a number of small packages might be warranted, given the diversity and number of files. In several cases just extracting the Fortran and C and re-introducing the documentation into the subpackages would make things more manageable.
I have used fpm with larger projects, including GPF (around 2117 F and 200 C files and about 420 000, lines sans comments and whitespace) and it works but has problems with command line lengths and compilation cascades so I think smaller packages is not only more natural but well advised given the size of the collection.
@urbanjost go ahead and report all fpm bugs for large projects. Iāll try to organize fixing them.
1 Like
Yes it would be interesting to know more as @certik is suggesting. AFAICT the only open command line length issue is for Windows: fpm #991 and it will require significant refactoring of the build process. Comments and ideas are always appreciated 
1 Like
Burkhardt makes each of his many projects self-contained. For a source file foo.f90 there is typically a file foo_test.f90 such that
gfortran foo.f90 foo_test.f90 creates an executable. This is convenient for someone who wants to work with a single project but results in duplication of utility procedures that are used in many codes.
Given a .o object file created by gfortran -c, the nm command can be used to list functions and subroutines defined in that object file, with output such as
0000000000000020 T hello_
0000000000000000 T twice_
for an object file containing procedures hello and twice.
I wrote a Python script to create a list of names that are defined in multiple source files of a directory and its subdirectories. Running it on Burkardtās codes gives a list of 2000+ procedures that are defined in more than one source file, for example
name #files
timestamp 795
get_unit 291
r8vec_print 154
ch_cap 143
s_to_i4 123
ch_to_digit 118
ch_eqi 117
s_to_r8 115
r8mat_print 93
r8mat_print_some 91
s_word_count 80
...
To organize his codes into a library, one step would be to create modules with utility procedures that are used in many places and to remove those procedures from the other source files.
3 Likes
Thanks for providing this. JB codes are very useful, I have used his interpolation and function fitting routines in the past.
However, I noticed that he often does not write intent(in), out, etc when declaring arguments in functions and subroutines. This makes some of the code less easy to read (at least for me).
The above is to say that it would be great to āmodernizeā some of his codes, starting from simple features of Fortran 90 and 95 such as the intent declaration
1 Like
Other things that I would put on the list of modernisation tasks:
- KIND numbers 4 and 8 should be made generic via the ISO_FORTRAN_ENV module
- Use explicit interfaces for functions. Some of the functions that are used in another function are not declared with their interface, but merely via their return value. In asa005.f90 the function tfn is defined, but declared when used as
real (kind = 8 ) tfn. Of course this would be automatic when the code is wrapped into modules. - Generic interfaces for variants of functions - in particular functions that work for single and double precision. I see for instance a function r8_uniform_01 in asa159.f90 - the prefix r8 indicates the type of the return value, but that should be irrelevant to the user.
- More descriptive names for functions and subroutines. In that same file, rcont2 is the name of a subroutine that constructs a particular kind of two-way contingency table. The name does not convey this information. Easily solved via an interface in a module.
- Remove the writing of errors to standard output. For a library that should be left to the discretion of the user.
- And no doubt the list can be extended
This could actually be a nice use case for the Codee product.
2 Likes
Most were reported. #669 might still occur in some environments but I built in Cygwin successfully. The remaining issues are time-related and unneeded recompilations. On the only MSWindows machine I have access to (an old small laptop) it takes over an hour to compile the GPF, and MSWindows is where most problems remain so it may take a while to quantify the problems; but it is generally much faster on other platforms, particularly if compiled with parallel mode. So I can build on MSWindows, Unix, and Linux; just not optimally. Using the time and performance of the make(1) file available as an alternative build method, the differences are substantial though ā¦
git clone https://github.com/urbanjost/general-purpose-fortran
cd general_purpose_fortran
fpm build
cd src
make
assuming the default compiler is gfortran demonstrates the problem. Then in what can appear to be an arbitrary manner changing a file such as a demo program can cause many modules to be rebuilt. I will try to quantify it a bit more, but others have reported the unexpected recompiles and I think I have over a dozen issues open already.
1 Like