procedures contained in modules

[gsal]

trafficstars

Say, I noticed procedures contained in modules are not being listed. Am I missing something or is this not implemented, yet?

Thanks

[cmacmackin]

Could you be more specific? Not being listed where? Are these procedures public or private? Have you set

display: private
        protected
        public

in your project file?

[gsal]

Hhhhmmm...never mind for the moment. I went ahead and put together a minimal test program with a module and the subroutine inside the module is collected and listed under the Procedures tab (navigation bar), see sub write_something, below.

$ cat main.f90 
program main
end program

$ cat amodule.f90 
module amodule
contains
  subroutine write_something()
    write(*,*) ' something'
  end subroutine
end module amodule

$ cat asub.f90 
subroutine asubroutine
    write(*,*) ' writing from within asubroutine'
end subroutine asubroutine

It is just that this does not quite happen within my real project.

With --warn and --debug, both the test program and my project indicate that the subroutine is Undocumented; at the end, though, the minimal test program shows it and my project does not. Then again, my project is larger and with a bunch of undeclared variables in between, etc.

Other than that, ford does not fail; but in my project, it just does not show me any subs/functions from within the contains clause of modules or other subroutines.

That's all I can say, at the moment.

gsal

[gsal]

O.k., just noticed something.

If I remove the line display: public private protected from the project file, then, all those contained procedures show up; I guess it has something to do with the fact that I am actually not using any of those attributes.

It is my understanding that if I do not specify public nor private, then, by default, everything is public; could it be that this default condition is not being recognized by FORD?

Thanks

[d7919]

You need to make sure that you only give one entry per line in the display: section (I think) so instead of display: public private protected you probably want

display: public
         private
         protected

to include everything. I think the case where you put them all on one line corresponds to ford thinking you've overridden the default (by setting display to something) but that it doesn't recognise your choice so ends up with display: None effectively.

[gsal]

I see; and, I think you are correct. I just went back to the documentation and carefully read that option, it does say that it needs one option per line...then, again, I had based my project file on the example provided...I guess that example needs to be better formatted...

Thanks.

[d7919]

I had the same issue when I first started as well as I was viewing the example using github's markdown rendering as it doesn't respect the newlines -- if you click on raw then you can see the correct format.

[gsal]

Hhhhmmm...maybe the project settings file should be a file of its own in good old plain text; instead of trying to mix settings and Markdown in the same file.

[d7919]

I think it's probably done this way for two reasons:

1. As it's possible to override settings in specific source files. By making the settings be markdown metadata the parsing of settings overrides can come under part of the standard markdown parsing, I'm guessing.
2. The settings file doubles up as a way to write a markdown introduction page that becomes index.html

I think maybe the example config file could be included in "raw" mode in the wiki and perhaps a line could be added near the start of the example that notes the potential issue with displaying this file.

Maybe it's enough to rename the example from .md in order to try and avoid github trying to render it?

[zbeekman]

It is my understanding that if I do not specify public nor private, then, by default, everything is public; could it be that this default condition is not being recognized by FORD?

I'm not 100% certain of this, but I'm guessing internal procedures are treated as private, since they are local to the scope, unless they are module procedures.

Hhhhmmm...maybe the project settings file should be a file of its own in good old plain text; instead of trying to mix settings and Markdown in the same file.

Again, I haven't tested it, but I believe you can specify the project meta data in a separate file and then use markdown include at the top of the main project markdown file to pull in the meta data. (Assuming the include happens before the meta-data is parsed...)